a2) United States Patent
`US 6,874,148 Bl
`(10) Patent No.:
`Mar.29, 2005
`(45) Date of Patent:
`Richardsonet al.
`
`US006874148B1
`
`(54)
`
`(75)
`
`(73)
`
`SYSTEM AND METHOD FOR EXPORTING A
`GRAPHICAL PROGRAM TO A SHARED
`LIBRARY
`
`Inventors: Greg Richardson, Round Rock, TX
`(US); Steve Rogers, Austin, TX (US)
`
`Assignee: National Instruments Corporation,
`Austin, TX (US)
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`US.C. 154(b) by 525 days.
`
`(21)
`
`Appl. No.: 09/594,226
`
`(22)
`
`Filed:
`
`Jun. 14, 2000
`
`61)
`
`(52)
`(58)
`
`(56)
`
`Int. C17 occ G06F 3/00; GO6F 9/44;
`GO06F 9/46; GO6F 13/00
`US. Che cence 719/328; 719/331; 717/107
`Field of Search .........0.......00. 719/310, 311-316,
`719/328-331; 717/100-113, 162-167, 133,
`144, 157; 709/331, 332; 345/762, 763,
`TT, 967
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,146,593
`5,163,130
`5,860,004
`5,883,639
`6,064,812
`6,102,965
`6,189,138
`6,351,778
`6,389,588
`
`9/1992 Brandle et al.
`A *
`........... 709/328
`A * 11/1992 Hullot wee 345/763
`
`1/1999 Fowlowet al. 0.0... 717/109
`A *
`3/1999 Walton et al. 00... 345/473
`A *
`A
`5/2000 Parthasarathyet al.
`A
`8/2000 Dyeetal.
`Bi *
`2/2001 Fowlowetal. ............. 717/107
`Bi *
`2/2002 Ortonetal.
`
`5/2002 Wadhwaetal. ............ 717/106
`Bl *
`
`
`OTHER PUBLICATIONS
`
`Munro, Writing DLLs for Windowsusing Visual Basic, part
`1, PC Magazine, v11, n11,p. 379(6).*
`LabVIEW Function Reference Manual, Aug. 1993 Edition,
`pp 10-11 and 10-12.
`LabVIEW CodeInterface Reference Manual, Dec. 1993.
`
`* cited by examiner
`Primary Examiner—Meng-Al T. An
`Assistant Examiner—Diem Cao
`(74) Attorney, Agent, or Firm—Meyertons Hood Kivlin
`Kowert & Goetzel, P.C.; Jeffrey C. Hood; Jason L. Burgess
`(57)
`ABSTRACT
`
`System and method for enabling a program to call into
`graphical program code via a shared library. A graphical
`programming system may export a graphical program to a
`shared library, such as a Windows Dynamic Link Library
`(DLL), Unix Shared Library, etc. A program, e.g. a text-
`based program, may then use the shared library to call into
`the graphical program. Graphical programs or subprograms
`may have associated inputs or outputs of various data types.
`Whencreating a shared library, a functional interface speci-
`fying parameterized versions of these inputs and outputs
`may be specified, either automatically or interactively. A
`program maythen utilize this functional interface to con-
`struct an appropriate call
`into the shared library. A user
`interface enabling users to specify the mapping of graphical
`program inputs and outputs onto parameters of the func-
`tional interface is described. Multiple graphical programsor
`subprograms maybe exported to a sharedlibrary. The shared
`library may include an entry point function associated with
`each graphical program or subprogram. When a program
`calls into the entry point associated with a particular graphi-
`cal program, the entry point function may manipulate or
`copy the parameters passed by the calling program into a
`representation expected by the graphical program.
`
`38 Claims, 11 Drawing Sheets
`
`user chooses a graphical program to export to
`
`a shared library 200
`
`user specifies desired functionalinterface forthe shared
`library entry point for the graphical program code
`202
`
`
`
`
`|graphical programming environmentcreates the shared
`library, in response to a request by the user
`204DEE
`
`Program performsa call into the shared library in
`accordance with the specified functionalinterface
`206
`
`eeeeentry pointfunction transforms parameters into the
`
`appropriate data typesor formats expected by the
`graphical program code and copiesthe parameters into
`the locations expected by the graphical program code
`
`ee
`entry point function calls graphical program code
`210
`ft
`graphical program code executes
`212
`
`Google Exhibit 1062
`Google v. VirtaMove
`
`Google Exhibit 1062
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Mar.29, 2005
`
`Sheet 1 of 11
`
`US 6,874,148 B1
`
`oo”
`
`
`
`spieoguonisinbow
`
`vib
`
`
`
`BEL—-,Buluojipuod@uonisinboy
`9z1jeubis
`ebeu|©zel$2
`
`vEL
`
`9El
`
`VbSls
`
`jonUODuoROWY<2OSI
`
`paseg-sajndwoy
`
`SJUSWTUSU]
`
`
`
`SalJepuHwun
`
`
`
`
`

`

`U.S. Patent
`
`Mar.29, 2005
`
`Sheet 2 of 11
`
`US 6,874,148 B1
`
`uonoW
`
`|jU0DEL
`
`aunjesedwa|
`
`eiNsselda
`
`Wr
`
`al‘Sis
`
`8t1
`
`Puonsinboy
`
`eGbew)&
`
`vel
`
`sninwips
`
`joquoD
`
`—og
`
`arsjeubis
`velEfspseogvel
`
`c8bHy9Z|
`Guluon|puod
`
`BeQ-u-Bnid
`
`uonisinboy
`
`WOdPIsl4
`
`
`
`

`

`U.S. Patent
`
`Mar.29, 2005
`
`Sheet 3 of 11
`
`US 6,874,148 B1
`
`Aowsy\ule
`
`991
`
`JayjouyU04
`
`KowayyNdd
`
`vol
`
`é9Lsng}sOH
`
`
`
`Ja[jO1UODsng
`
`o9gL
`
`
`
`SISSEYD[XA
`
`ST
`
`¢Old
`
`LLSngaid9D
`
`PLL
`
`XW
`
`98L
`
`uonisinbow)es3calo8t
`Ws!JEDdidAUQPJeHoaplACJeyeq
`
`OZLsnguolsuedxy
`
`BOL
`
`
`
`
`

`

`U.S. Patent
`
`Mar. 29,2005
`
`Sheet 4 of 11
`
`US 6,874,148 B1
`
`user choosesa graphical program to export to
`a sharedlibrary
`200
`
`user specifies desired functional interface for the shared
`library entry point for the graphical program code
`202
`
`graphical programming environmentcreates the shared
`library, in response to a request by the user
`204
`
`_|FIG. 3A
`graphical program code executes
`
`program performsacall into the sharedlibrary in
`accordancewith the specified functional interface
`206
`
`entry point function transforms parameters into the
`appropriate data types or formats expected by the
`graphical program code and copies the parameters into
`the locations expected by the graphical program code
`208
`
`entry point function calls graphical program code
`210
`
`

`

`U.S. Patent
`
`Mar. 29,2005
`
`Sheet 5 of11
`
`US 6,874,148 B1
`
`(f) Ruild Application or Shared Library COLL) - New script *
`
`Target
`
`Saurce Files | VI Settings | Application Settings |
`
`Installer Settings |
`
`Build target
`Application nane
`Dertinazion directcry
`Support fle directory
`
`uild Optians
`
`|
`
`Fharod Library (DLL!
`[sharedib.ai
`q fe:\TENPano
`2 [c:\TEM>\appidata
`
`& Single application containngall VT<
`£ Small application wih external Fle far subvie
`
`[— Co not compress application
`Faster toad
`ti
`hines
`(Faster load
`on slow machine:)
`
`LLB For other files
`
`3% c:\ TEMPyapp\data lib
`
`Gar |
`ae i
`
`|
`
`Add Exported VI...
`Add Dynamic 47...
`Add Support File...
`Add Diractory Contante...
`
`Target
`
`Source Files
`
`| VI Settings | Application Settings |
`
`Installer Settings |
`
`(SgeaeeRea
`W My Scope Read Waveform.vi
`My Scope Configurs Yertca.vt
`
`Source file path
`
`1 Prvswerewinda\SampleVisiMySwitchGetPath.vi
`
`7
`
`FIG. 4B
`
`|
`|
`|
`|
`
`|
`
`|
`
`RemoveFie
`
`Define YI Prototype...
`
`CisstomDestinations ..
`
`

`

`U.S. Patent
`
`Mar. 29, 2005
`
`Sheet6 of 11
`
`US 6,874,148 B1
`
`(>[| LN) [Spt AppicationFont —_~]
`
`|
`
`Index|
`4
`
`|
`
`Waveform Point|
`ooo
`
`FIG. 5A
`
`
`
`FIG. 5B
`
`

`

`U.S. Patent
`
`Mar. 29,2005
`
`Sheet 7 of11
`
`US 6,874,148 B1
`
`user specifies entry point function name
`220
`
`222
`
`user defines parameters for entry point function,
`naming and ordering the parameters as desired
`
`user selects a particular parameter
`224
`
`
`
`
`
`
`
`
`
`
`
`
`graphical programming environmentdisplays
`mapping information for the selected parameter
`226
`
`
`
`user associates the parameter with the
`appropriate input and/or output of the
`graphical program
`228
`
`
`
`
`
`
`
`user specifies desired data type mapping
`information for the parameter, if necessary
`
`
`230
`
`
`
`FIG. 6
`
`

`

`U.S. Patent
`
`Mar. 29, 2005
`
`Sheet 8 of 11
`
`US 6,874,148 B1
`
`iS Define VI Prototype
`
`Fa
`
`Function Name
`7 SwitchGetPath
`¥
`& Standard CallingConventions
`Calling Convertions
`
`Parameters
`
`return value
`channel2
`
`Coe
`
`[eIe)
`
`‘urrent Parameter
`Name fans
`
`Param Typs
`|
`¥I Output
`Pass By j
`Length Input
`Length Outpct
`
`f
`
`Output
`pathlist
`C String Pointer
`lon
`len2
`
`7
`=]
`J
`°
`J
`
`Function Frototype:
`pid MySvitchGetPath(LStrHandle “channel2, LStrHandk “channelt, int32 vi,
`CStr pathtist, int32 len, intaz “lenz)
`
`
`
`FIG. 7
`
`

`

`U.S. Patent
`
`Mar.29, 2005
`
`Sheet 9 of 11
`
`US 6,874,148 B1
`
`
`
`ZOE
`
`vOE
`
`
`
`
`
`wesBoudyeolydes6
`
`poveys 00€
`pareus
`
`
`
`
`uoNeWwojuy;bue}@pooajqe}noexaweJsGoidjeoiydes6
`.Oe8“OldAveiqypeseys=\
`90€pOE
`
`
`apooaiqeynoexawesHodjeordesB
`
`apoojuiodAnusAeiqi
`
`
`apoojuiodAnusAveiqy
`
`00€
`
`
`
`

`

`U.S. Patent
`
`Mar. 29,2005
`
`Sheet 10 of 11
`
`US 6,874,148 B1
`
`CodeView Debug Information
`
`COFF Symbols
`
`COFF Line Numbers
`
`
` Sections
`
`Section Table (array of
`IMAGE_SECTION_
`HEADERs)
`
`|
`
`Data Directory
`
`|
`
`IMAGE_NT_
`HEADERS
`
`Offset 0
`
`IMAGE_OPTIONAL
`_HEADER
`eee
`IMAGE_FILE_HEADER
`"PE\O\O"-
`MZ
`Ww
`i
`
`PE Signature
`MS-DOS Header
`_
`H
`
`FIG. 9
`(PRIOR ART)
`
`

`

`U.S. Patent
`
`Mar. 29,2005
`
`Sheet 11 of 11
`
`US 6,874,148 B1
`
`program Calls into shared library entry point function
`400
`
`entry point function transforms and copies parameters
`402
`|
`
`406
`
`entry point function calls into runtime system, specifying
`the graphical program to be executed
`404
`
`runtime system manages execution of graphical
`program
`
`FIG. 10
`
`

`

`US 6,874,148 B1
`
`1
`SYSTEM AND METHOD FOR EXPORTING A
`GRAPHICAL PROGRAM TO A SHARED
`LIBRARY
`
`FIELD OF THE INVENTION
`
`The present invention relates to the field of graphical
`programming, and moreparticularly to a system and method
`for enabling a program to call into graphical program code
`via a shared library.
`DESCRIPTION OF THE RELATED ART
`
`text-based programming lan-
`Traditionally, high level
`guages have been used by programmers in writing applica-
`tions programs. Many different high level programming
`languages exist, including BASIC, C, FORTRAN,Pascal,
`COBOL, ADA, APL, etc. Programs written in these high
`level languagesare translated to the machine languagelevel
`by translators known as compilers or interpreters. The high
`level programming languages in this level, as well as the
`assembly language level, are referred to as text-based pro-
`gramming environments.
`Increasingly computers are required to be used and pro-
`grammed by those whoare not highly trained in computer
`programming techniques. When traditional text-based pro-
`gramming environments are used, the user’s programming
`skills and ability to interact with the computer system often
`become a limiting factor in the achievement of optimal
`utilization of the computer system.
`There are numerous subtle complexities which a user
`must master before he can efficiently program a computer
`system in a text-based environment. The task of program-
`ming a computer system to model or implement a process
`often is further complicated by the fact that a sequence of
`mathematical formulas, mathematical steps or other proce-
`dures customarily used to conceptually model a process
`often does not closely correspond to the traditional text-
`based programming techniques used to program a computer
`system to model such a process. In other words, the require-
`ment
`that a user program in a text-based programming
`environmentplaces a level of abstraction betweenthe user’s
`conceptualization of the solution and the implementation of
`a method that accomplishes this solution in a computer
`program. Thus, a user often must substantially master dif-
`ferent skills in order to both conceptually model a system
`and then to program a computer to model that system. Since
`a user often is not fully proficient in techniques for pro-
`gramming a computer system in a text-based environmentto
`implement his model, the efficiency with which the com-
`puter system can beutilized to perform such modeling often
`is reduced.
`
`
`
`Examples of fields in which computer systems are
`employed to model and/or control physical systems are the
`fields of instrumentation, process control,
`industrial
`automation, and simulation. Computer modeling or control
`of devices such as instruments or industrial automation
`
`hardware has becomeincreasingly desirable in view of the
`increasing complexity and variety of instruments and
`devices available for use. However, due to the wide variety
`of possible testing/control situations and environments, and
`also the wide array of instruments or devices available,it is
`often necessary for a user to develop a program to control a
`desired system. As discussed above, computer programs
`used to control such systems had to be written in conven-
`tional
`text-based programming languages such as,
`for
`example, assembly language, C, FORTRAN, BASIC, or
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`Pascal. Traditional users of these systems, however, often
`were not highly trained in programming techniques and, in
`addition,
`traditional
`text-based programming languages
`were not sufficiently intuitive to allow users to use these
`languages without training. Therefore, implementation of
`such systems frequently required the involvement of a
`programmer to write software for control and analysis of
`instrumentation or industrial automation data. Thus, devel-
`opment and maintenance of the software elements in these
`systems often proved to be difficult.
`U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,
`301; and 5,301,336; among others, to Kodoskyet al disclose
`a graphical system and method for modeling a process,Le.,
`a graphical programming environment which enables a user
`to easily and intuitively model a process. The graphical
`programming environmentdisclosed in Kodoskyet al can be
`considered the highest and most intuitive way in which to
`interact with a computer. A graphically based programming
`environment can be represented at a level above text-based
`high level programming languages such as C, Pascal, etc.
`The method disclosed in Kodosky et al allows a user to
`construct a diagram using a block diagram editor, such that
`the diagram created graphically displays a procedure or
`method for accomplishing a certain result, such as manipu-
`lating one or more input variables to produce one or more
`output variables. In response to the user constructing a data
`flow diagram or graphical program using the block diagram
`editor, data structures are automatically constructed which
`characterize an execution procedure which corresponds to
`the displayed procedure. The graphical program may be
`compiled or interpreted by a computer. Therefore, a user can
`create a computer program solely by using a graphically
`based programming environment. This graphically based
`programming environment may be usedfor creating virtual
`instrumentation systems,
`industrial automation systems,
`modeling processes, and simulation, as well as for any type
`of general programming.
`Therefore, Kodosky et al teaches a graphical program-
`ming environment wherein a user places or manipulates
`icons in a block diagram using a block diagram editor to
`create a data flow “program.” A graphical program for
`controlling or modeling devices, such as instruments, pro-
`cesses or industrial automation hardware, maybereferred to
`as a virtual instrument (VI). In creating a virtual instrument,
`a user may create a front panel or user interface panel. The
`front panel includes various user interface elements or front
`panel objects, such as controls or indicators, that represent or
`display the respective input and output that will be used by
`the graphical program or VI, and may include other icons
`which represent devices being controlled. The front panel
`may be comprised in a single window of user interface
`elements, or may comprise a plurality of individual windows
`each having a user interface element, wherein the individual
`windows mayoptionally be tiled together. Whenthe controls
`and indicators are created in the front panel, corresponding
`icons or terminals may be automatically created in the block
`diagram by the block diagrameditor. Alternatively, the user
`can place terminal icons in the block diagram which may
`cause the display of corresponding front panel objects in the
`front panel, either at edit time orlater at run time. As another
`example,
`the front panel objects, e.g.,
`the GUI, may be
`embedded in the block diagram.
`During creation of the graphical program, the user may
`select various function nodes or icons that accomplish his
`desired result and connect the function nodes together. For
`example, the function nodes may be connected in a data flow
`or control flow format. The function nodes may be con-
`
`

`

`US 6,874,148 B1
`
`3
`4
`graphical program code via a shared library. A user may
`nected between the terminals of the respective controls and
`indicators. Thus the user may create or assemble a data flow
`utilize a graphical programming system to create a graphical
`program, referred to as a block diagram, representing the
`program and may then export this graphical program to a
`graphical data flow which accomplishes his desired process.
`shared library. The graphical programming system may
`The assembled graphical program may then be compiled or
`support
`the creation of any of various types of shared
`interpreted to produce machine language that accomplishes
`libraries, such as a Windows Dynamic Link Library (DLL),
`the desired method or process as shown in the block dia-
`a Unix or Linux Shared Library, a Macintosh Code
`gram.
`Fragment, etc. A program enabled to interface with the type
`A user may input data to a virtual instrument using front
`of shared library created by the graphical programming
`panel controls. This input data may propagate through the
`system may then use the shared library to call into the
`data flow block diagram or graphical program and appear as
`graphical program. For example, the graphical programming
`changes on the output
`indicators.
`In an instrumentation
`system may create a Windows DLL,andatext-based C
`application, the front panel can be analogized to the front
`program running on the Windows environment may load
`panel of an instrument. In an industrial automation applica-
`and use the DLL.
`tion the front panel can be analogized to the MMI (Man
`Machine Interface) of a device. The user may adjust the
`controls on the front panel to affect the input and view the
`output on the respective indicators. Alternatively, the front
`panel may be used merely to view the input and output, and
`the input may not be interactively manipulable by the user
`during program execution.
`Thus, graphical programming has become a powerfultool
`available to programmers. Graphical programming environ-
`ments such as the National Instruments LabVIEW product
`have become very popular. Tools such as LabVIEW have
`greatly increased the productivity of programmers, and
`increasing numbers of programmers are using graphical
`programming environments to develop their software appli-
`cations.In particular, graphical programmingtools are being
`used for test and measurement, data acquisition, process
`control, man machine interface (MMI), supervisory control
`and data acquisition (SCADA)applications, simulation, and
`machine vision applications, among others.
`As the use of graphical programming hasincreased,it has
`become more important to enable graphical programs to
`interface with other types of executable code. One common
`wayfor interfacing between different portions of executable
`code is to use a standard shared library. Many computing
`platforms support standard shared libraries. For example, the
`Windows platform supports Dynamic Link Libraries
`(DLLs), the Unix platform supports Shared Libraries, and
`the Macintosh platform supports Code Fragments. Many
`programming environments, including text-based program-
`ming environments, support the creation and use of these
`types of standard shared libraries.
`Somecurrent graphical programming environments pro-
`vide a node for calling a standard shared library from within
`a graphical program. In this way, graphical programs can
`utilize other types of executable code, including code cre-
`ated from a text-based programming language. However,it
`is often desirable to provide the reverse functionality, in
`which another program can call into a graphical program
`using a shared library. Previous approaches to enabling
`graphical programsto be called using sharedlibraries suffer
`from various drawbacks. For example, one approach in
`current use for the Windowsplatform is to create a DLL that
`has entry points that call a graphical program indirectly by
`interfacing with an ActiveX out-of-process server, where
`this ActiveX server is operable to invoke the desired graphi-
`cal program. However, calling a graphical program using
`this method may be inefficient, since a process switch is
`involved. Also, this approach may require programmers to
`understand various aspects of the ActiveX framework. Thus,
`it may be desirable to enable programmers to call into
`graphical program code more easily and efficiently.
`SUMMARYOF THE INVENTION
`
`Graphical programs or subprograms may have associated
`inputs or outputs of various data types. When creating a
`shared library from a graphical program, a functional inter-
`face specifying parameterized versions of these inputs and
`outputs may be specified, either automatically or interac-
`tively. A program may then utilize this functional interface
`to construct an appropriate call into the shared library. For
`example, for a graphical program with an integer input and
`an integer output, a C-style functional interface may be
`specified, such as:
`int Funcname(int inputParm);
`A user interface enabling users to specify the mapping of
`graphical program inputs and outputs onto parameters of the
`functional interface is described.
`A user may specify multiple graphical programs or sub-
`programs to export to a shared library. The shared library
`may include an entry point function associated with each
`graphical program or subprogram. When a program calls
`into the entry point associated with a particular graphical
`program, the entry point function may manipulate or copy
`the parameters passed by the calling program. For example,
`a graphical program mayrepresentor store a particular data
`type differently than the calling program or the shared
`library specification. Thus,
`the entry point function may
`perform any necessary operationsto transform the parameter
`into the format expected by the graphical program. The entry
`point function may also copy parameters into a location
`expected by the graphical program, such as a parameter table
`associated with the graphical program.
`The entry point function may then call into the graphical
`program code. In one embodiment, a runtime execution
`system associated with the graphical programming system
`used to create the shared library may manage the execution
`of the graphical program code.
`Thus, the present invention allows a graphical program to
`be exported to a shared library, thereby enabling any pro-
`gram able to access a shared library to be able to access a
`graphical program through a shared library.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`A better understanding of the present invention can be
`obtained when the following detailed description of the
`preferred embodimentis considered in conjunction with the
`following drawings, in which:
`FIGS. 1A and 1B illustrate representative instrumentation
`and process control systems including various I/O interface
`options;
`FIG. 2 is a block diagram of the computer system of
`FIGS. 1A and 1B;
`FIG. 3A is a flowchart diagram illustrating one embodi-
`ment of a method for creating a shared library including
`graphical program code;
`
`The problems outlined above may in large part be solved
`by a system and method for enabling a program to call into
`
`

`

`US 6,874,148 B1
`
`5
`FIG. 3B is a flowchart diagram illustrating one embodi-
`ment of a method for using a shared library to invoke a
`graphical program;
`FIGS. 4A and 4B illustrate one embodiment of a user
`interface for creating a shared library;
`FIGS. 5A and 5B illustrate an exemplary graphical pro-
`gram andits user interface;
`TIG. 6 is a flowchart diagram illustrating one embodiment
`of a methodfor specifying a functional interface for a shared
`library entry point function for a graphical program;
`FIG. 7 illustrates an exemplary user interface for speci-
`fying a functional interface for a shared library entry point
`function for a graphical program;
`FIG. 8 illustrates one embodiment of creating a shared
`library including graphical program code;
`FIG. 9 (prior art) illustrates various elements of a 32-bit
`Windows DLL;
`FIG. 10 is a flowchart diagram illustrating an embodiment
`in which a runtime execution system managesthe execution
`of a graphical program invoked via a shared library.
`While the invention is susceptible to various modifica-
`tions and alternative forms, specific embodiments thereof
`are shownby wayof example in the drawings and are herein
`described in detail. It should be understood, however, that
`the drawings and detailed description thereto are not
`intended to limit
`the invention to the particular form
`disclosed, but on the contrary, the intention is to coverall
`modifications, equivalents and alternatives falling within the
`spirit and scope of the present invention as defined by the
`appended claims.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`FIGS. 1A and 1B—Instrumentation and Industrial Automa-
`
`tion Systems
`FIGS. 1A and 1B illustrate exemplary systems that may
`store or execute graphical programs for instrumentation,
`process control, or other purposes. These programs may of
`course be stored in or used by other types of systems as
`desired. In accordance with the present system and method,
`code associated with the graphical programs may be
`included in a shared library that may be called by other
`programs, as described below.
`FIG. 1A illustrates an instrumentation control system 100.
`The system 100 comprises a host computer 102 which
`connects to one or more instruments. The host computer 102
`comprises a CPU, a display screen, memory, and one or
`more input devices such as a mouseor keyboard, as shown.
`The host computer 102 connects through the one or more
`instruments to analyze, measure, or control a unit undertest
`(UUT) or process 150.
`The host computer 102 may execute a graphical program
`which interacts with or controls the one or more instruments.
`
`The one or more instruments may include a GPIB instru-
`ment 112 and associated GPIB interface card 122, a data
`acquisition board 114 and associated signal conditioning
`circuitry 124, a VXI instrument 116, a PXI instrument 118,
`a video device 132 and associated image acquisition card
`134, a motion control device 136 and associated motion
`control interface card 138, and/or one or more computer
`based instrument cards 142, among other types of devices.
`The GPIB instrument 112 is coupled to the computer 102
`via the GPIB interface card 122 provided by the computer
`102. In a similar manner, the video device 132 is coupled to
`the computer 102 via the image acquisition card 134, and the
`motion control device 136 is coupled to the computer 102
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`through the motion control interface card 138. The data
`acquisition board 114 is coupled to the computer 102, and
`may interface through signal conditioning circuitry 124 to
`the UUT. The signal conditioning circuitry 124 preferably
`comprises an SCXI (Signal Conditioning eXtensions for
`Instrumentation) chassis comprising one or more SCXI
`modules 126.
`The GPIB card 122, the image acquisition card 134, the
`motion control interface card 138, and the DAQ card 114 are
`typically plugged in to an I/O slot in the computer 102, such
`as a PCI bus slot, a PC Card slot, or an ISA, EISA or
`MicroChannel bus slot provided by the computer 102.
`However, these cards 122, 134, 138 and 114 are shown
`external to computer 102 for illustrative purposes.
`The VXI chassis or instrument 116 is coupled to the
`computer 102 via a VXI bus, MXIbus,or other serial or
`parallel bus provided by the computer 102. The computer
`102 preferably includes VXIinterface logic, such as a VXI,
`MXIor GPIB interface card (not shown), which interfaces
`to the VXI chassis 116. The PXI chassis or instrument is
`preferably coupled to the computer 102 through the com-
`puter’s PCI bus.
`A serial instrument (not shown) may also be coupled to
`the computer 102 through a serial port, such as an RS-232
`port, USB (Universal Serial bus) or IEEE 1394 or 1394.2
`bus, provided by the computer 102. In typical instrumenta-
`tion control systems an instrument will not be present of
`each interface type, and in fact many systems may only have
`one or more instruments of a single interface type, such as
`only GPIB instruments.
`The instruments are coupled to the unit under test (UUT)
`or process 150, or are coupled to receive field signals,
`typically generated by transducers. The system 100 may be
`used in a data acquisition and control application, in a test
`and measurement application, a process control application,
`or a man-machine interface application.
`FIG. 1B illustrates an exemplary industrial automation
`system 160. The industrial automation system 160 is similar
`to the instrumentation or test and measurement system 100
`shownin FIG. 1A. Elements which are similar or identical
`to elements in FIG. 1A have the samereference numerals for
`
`convenience. The system 160 comprises a computer 102
`which connects to one or more devices or instruments. The
`
`computer 102 comprises a CPU, a display screen, memory,
`and one or more input devices such as a mouse or keyboard
`as shown. The computer 102 connects through the one or
`more devices to a process or device 150 to perform an
`automation function, such as MMI
`(Man Machine
`Interface), SCADA (Supervisory Control and Data
`Acquisition), portable or distributed data acquisition, pro-
`cess control, advanced analysis, or other control. In FIG. 1B,
`the computer 102 may execute a graphical program that is
`involved with the automation function performed by the
`automation system 160. Similarly as noted above with
`reference to FIG. 1A,
`the graphical program may be
`included in a shared library that may be called by other
`programs.
`The one or more devices may include a data acquisition
`board 114 and associated signal conditioning circuitry 124,
`a PXI instrument 118, a video device 132 and associated
`image acquisition card 134, a motion control device 136 and
`associated motion control
`interface card 138, a fieldbus
`device 170 and associated fieldbus interface card 172, a PLC
`(Programmable Logic Controller) 176, a serial instrument
`182 and associated serial interface card 184, or a distributed
`data acquisition system, such as the Fieldpoint system
`available from National Instruments, among other types of
`devices.
`
`

`

`US 6,874,148 B1
`
`10
`
`15
`
`20
`
`25
`
`30
`
`8
`7
`The DAQcard 114, the PXI chassis 118, the video device
`FIG. 2—Computer System Block Diagram
`FIG. 2 is an exemplary block diagram of the computer
`132, and the image acquisition card 136 are preferably
`system illustrated in FIGS. 1A and 1B. It is noted that any
`connected to the computer 102 as described above. The
`type of computer system configuration or architecture can be
`serial instrument 182 is coupled to the computer 102 through
`used in conjunction with the system and method described
`a serial interface card 184, or through a serial port, such as
`herein, as desired, and FIG. 2 illustrates a representative PC
`an RS-232 port, provided by the computer 102. The PLC
`embodiment.It is also noted that the computer system may
`176 couples to the computer 102 through a serial port,
`be a general purpose computer system suchasillustrated in
`Ethernet port, or a proprietary interface. The fieldbus inter-
`FIGS. 1A and 1B, a computer implemented on a VXI card
`face card 172 is preferably comprised in the computer 102
`installed in a VXI chassis, a computer implemented on a PXI
`and interfaces through a fieldbus network to one or more
`fieldbus devices. Each of the DAQ card 114,the serial card
`card installed in a PXI chassis, or other types of embodi-
`ments. The elements of a computer not necessary to under-
`184, the fieldbus card 172, the image acquisition card 134,
`stand the present invention have been omitted for simplicity.
`and the motion control card 138 are typically plugged in to
`The computer 102 includesat least one central processing
`an I/O slot
`in the computer 102 as described above.
`However, these cards 114, 184, 172, 134, and 138 are shown
`unit or CPU 160 which is coupled to a processor or host bus
`162. The CPU 160 may beany of various types, including
`external to computer 102 for illustrative purposes. In typical
`an x86 processor, e.g., a Pentium class, a PowerPC
`industrial automation systems a device will not be present of
`processor,
`a CPU from the SPARC family of RISC
`each interface type, and in fact many systems mayonly have
`processors, as well as others. Main memory 166 is coupled
`one or more devices of a single interface type, such as only
`to the host bus 162 by means of memory controller 164. The
`PLCs. The devices are coupled to the device or process 150.
`main memory 166 may store one or more computer pro-
`Referring again to FIGS. 1A and 1B, the computer system
`gramsor libraries according to the present invention. The
`102 preferably includes a memory medium on whichsoft-
`main memory 166 also stores operating system software as
`ware according to the present invention may be stored. The
`well as the software for operation of the computer system,
`memory medium