Patent Publication Number: US-2006005160-A1

Title: Image acquisition device

Description:
CONTINUATION DATA  
      This application is a divisional application of U.S. patent application Ser. No. 09/949,783 titled “System and Method for Deploying a Graphical Program on an Image Acquisition Device”, filed Sep. 10, 2001, whose inventors are Kevin L. Schultz, Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom and Cary Paul Butler, 
          which is a continuation-in-part of U.S. patent application Ser. No. 09/891,571 titled “System and Method for Configuring an Instrument to Perform Measurement Functions Utilizing Conversion of Graphical Programs into Hardware Implementations” filed on Jun. 25, 2001, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom, Cary Paul Butler, and Kevin L. Schultz,     which is a continuation-in-part of U.S. patent application Ser. No. 09/499,503 titled “System and Method for Configuring a Programmable Hardware Instrument to Perform Measurement Functions Utilizing Estimation of the Hardware Implementation and Management of Hardware Resources”, filed on Feb. 7, 2000, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom, Cary Paul Butler, and Andrew Mihal,     which is a continuation-in-part of U.S. patent application Ser. No. 08/912,427 titled “System and Method for Configuring an Instrument to Perform Measurement Functions Utilizing Conversion of Graphical Programs into Hardware Implementations”, filed on Aug. 18, 1997, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom and Cary Paul Butler, which is now U.S. Pat. No. 6,219,628.       

    
    
     FIELD OF THE INVENTION  
      The present invention relates to graphical programming, and in particular to a system and method for deploying a graphical program onto an image acquisition device. The present invention further relates to a system and method for configuring an image acquisition or machine vision device to perform image processing functions, wherein the instrument or device includes a programmable hardware element and/or a processor and memory.  
     DESCRIPTION OF THE RELATED ART  
      Traditionally, high level text-based programming languages have been used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level 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 programming environments.  
      Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user&#39;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 programming 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 procedures 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 requirement that a user program in a text-based programming environment places a level of abstraction between the user&#39;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 different 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 programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.  
      Examples of fields in which computer systems are employed to interact with physical systems are the fields of instrumentation, process control, industrial automation, and simulation. Computer measurement and control of devices such as instruments or industrial automation hardware has become increasingly 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 and control situations and environments, and also the wide array of instruments or devices available, it is often necessary for a user to develop a custom program to control a desired system.  
      As discussed above, computer programs used to control such systems traditionally had to be written in text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, etc. Traditional users of these systems, however, often were not highly trained in programming techniques and, in addition, 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, development 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 Kodosky et al disclose a graphical system and method for modeling a process, i.e., a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered a higher and more 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, Basic, Java, etc.  
      The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor. The block diagram may include a plurality of interconnected icons such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables and/or producing one or more output variables. In response to the user constructing a diagram or graphical program using the block diagram editor, data structures and/or program instructions may be automatically constructed which characterize an execution procedure that corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer.  
      Therefore, Kodosky et al teaches a graphical programming environment wherein a user places or manipulates icons and interconnects or “wires up” the icons in a block diagram using a block diagram editor to create a graphical “program.” A graphical program for performing an instrumentation, measurement or automation function, such as measuring a Unit Under Test (UUT) or device, controlling or modeling instruments, controlling or measuring a system or process, or for modeling or simulating devices, may be referred to as a virtual instrument (VI). Thus, a user can create a computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems, modeling processes, control, simulation, and numerical analysis, as well as for any type of general programming.  
      A graphical program may have a graphical user interface. For example, in creating a graphical program, a user may create a front panel or user interface panel. The front panel may include various graphical user interface elements or front panel objects, such as user interface controls and/or indicators, that represent or display the respective input and/or 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 one or more user interface elements, wherein the individual windows may optionally be tiled together. When the controls and indicators are created in the front panel, corresponding icons or terminals may be automatically created in the block diagram by the block diagram editor. 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 or later at run time. As another example, the front panel may comprise front panel objects, e.g., the GUI, embedded in the block diagram.  
      During creation of the block diagram portion 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 one or more of a data flow, control flow, and/or execution flow format. The function nodes may also be connected in a “signal flow” format, which is a subset of data flow. The function nodes may be connected between the terminals of the various user interface elements, e.g., between the respective controls and indicators. Thus the user may create or assemble a graphical program, referred to as a block diagram, graphically representing the desired process. The assembled graphical program may be represented in the memory of the computer system as data structures and/or program instructions. The assembled graphical program, i.e., these data structures, may then be compiled or interpreted to produce machine language that accomplishes the desired method or process as shown in the block diagram.  
      Input data to a graphical program may be received from any of various sources, such as from a device, unit under test, a process being measured or controlled, another computer program, or from a file. Also, a user may input data to a graphical program or virtual instrument using a graphical user interface, e.g., a front panel as described above. The input data may propagate through the data flow block diagram or graphical program and appear as changes on the output indicators. In an instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial automation application 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, or just the output, and the input may not be interactively manipulable by the user during program execution.  
      Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments 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 applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, simulation, image processing/machine vision applications, and motion control, among others.  
      A primary goal of graphical programming, including virtual instrumentation, is to provide the user the maximum amount of flexibility to create his/her own applications and/or define his/her own instrument functionality. In this regard, it is desirable to extend the level at which the user is able to program a device, e.g., extend the level at which a user of instrumentation or industrial automation hardware is able to program an instrument. The evolution of the levels at which the user has been able to program an instrument is essentially as follows. 
          1. User level software (LabVIEW, LabWindows CVI, Visual Basic, etc.)     2. Kernel level software     3. Auxiliary kernel level software (a second kernel running along side the main OS, e.g., InTime, VentureCom, etc.)     4. Embedded kernel level software     5. Hardware level software (FPGA)        

      In general, going down the above list, the user is able to create software applications which provide a more deterministic real-time response. Currently, some programming development tools for instrumentation or industrial automation provide an interface at level 1 above. In general, most users are unable and/or not allowed to program at the kernel level or auxiliary kernel level.  
      It would be highly desirable to provide the user with the ability to develop user level software which operates at the embedded kernel level and/or the hardware level. More particularly, it would be desirable to provide the user with the ability to develop high level software, such as graphical programs, which can then be readily deployed onto an image acquisition device, such as a smart camera. This would provide the user with the dual benefits of being able to program device functionality at the highest level possible (e.g., graphical programs), while also providing the ability to have the created program operate directly on an embedded processor or in hardware for increased speed and efficiency.  
     SUMMARY OF THE INVENTION  
      One embodiment of the present invention comprises a computer-implemented system and method for deploying a graphical program onto an image acquisition device, such as an image acquisition board coupled to or included in a computer system, or a smart camera. This provides the user the ability to develop or define desired functionality using graphical programming techniques, while enabling the resulting program to operate directly on an image acquisition device, such as a smart camera. The computer-implemented system and method may be used for configuring an image acquisition device or smart camera instrument to perform an image processing or machine vision function, where the image acquisition device (e.g., smart camera) includes at least one functional unit, such as a processor and memory, or a programmable hardware element.  
      The user may first create a graphical program which performs or represents the desired functionality. The graphical program may comprise a block diagram which includes a plurality of interconnected nodes which visually indicate functionality of the graphical program. The plurality of nodes may be interconnected in one or more of a data flow, control flow, or execution flow format. The graphical program may include a single diagram or a hierarchy of subprograms or sub-diagrams. In one embodiment, the user may place various constructs in portions of the graphical program to aid in conversion of these portions into hardware form. As the user creates or assembles the graphical program on the display, data structures and/or software code may be automatically created and stored in memory corresponding to the graphical program being created. In an image acquisition or analysis application, the graphical program may implement an image processing function. More generally, in a measurement or instrumentation application, the graphical program may implement a measurement function. A portion of the graphical program may also implement a user interface, described below.  
      Thus, in one embodiment, the graphical program may be created or assembled by the user arranging on a display a plurality of nodes or icons and then interconnecting the nodes to create the graphical program. In response to the user assembling the graphical program, data structures (and/or program instructions) may be created and stored which represent the graphical program. The graphical program may thus comprise a plurality of interconnected nodes or icons which visually indicates the functionality of the program. As noted above, the graphical program may comprise a block diagram and may also include a user interface portion or front panel portion. Where the graphical program includes a user interface portion, the user may assemble the user interface on the display.  
      In one embodiment, the graphical program may be create on or stored on a computer system. The method may comprise coupling the image acquisition device to the computer system which stores the graphical program, and, where the image acquisition device includes a functional unit, deploying the graphical program onto the functional unit in the image acquisition device to configure the functional unit. After the deployment of the graphical program, the functional unit may be operable to implement the graphical program. In one embodiment, the image acquisition device may be disconnected from the computer system after deploying the graphical program. The image acquisition device may also be coupled to the computer system over a network, and deploying the graphical program may include the computer system deploying the graphical program over the network to the image acquisition device.  
      In one embodiment, a computer-implemented method for configuring an image acquisition device (or smart camera) to perform an image processing function may include creating a graphical program on a computer system, as described above, where the graphical program implements the image processing function, and where the graphical program comprises a plurality of interconnected nodes which visually indicate functionality of the graphical program; deploying the graphical program on the image acquisition device, where the image acquisition device is coupled to or comprised in the computer system; the image acquisition device acquiring an image of an object; and the image acquisition device executing to perform the image processing function on the image.  
      In one embodiment, the image acquisition device may include a processor and a memory, and deploying the graphical program on the image acquisition device may include transferring the graphical program to the memory on the image acquisition device, where the image acquisition device executing to perform the image processing function on the image includes the processor in the image acquisition device executing the graphical program from the memory. In one embodiment, deploying the graphical program on the image acquisition device may include generating an executable program, such as a machine language program, based on the graphical program, which implements at least a portion of the functionality of the graphical program; and transferring the executable program to the memory on the image acquisition device. In one embodiment, compiling the graphical program into an executable program may comprise converting the graphical program first into a text-language program, and then compiling the text-language program into the executable program. The image acquisition device executing to perform the image processing function on the image may include the processor in the image acquisition device executing the executable program from the memory.  
      In one embodiment, the image acquisition device may include a programmable hardware element, and deploying the graphical program on the image acquisition device may include generating a hardware description based on the graphical program, which describes a hardware implementation of the graphical program, and configuring the programmable hardware element in the image acquisition device utilizing the hardware description. After being configured with the hardware description the programmable hardware element may implement a hardware implementation of the graphical program. The image acquisition device executing to perform the image processing function on the image may include the programmable hardware element in the image acquisition device executing to perform the image processing function on the image.  
      In one embodiment, the image acquisition device may include a processor and a memory and a programmable hardware element. In this embodiment, deploying the graphical program on the image acquisition device may include transferring a first portion of the graphical program to the memory on the image acquisition device; generating a hardware description based on a second portion of the graphical program, which describes a hardware implementation of the graphical program; and configuring the programmable hardware element in the image acquisition device utilizing the hardware description. After being configured, the programmable hardware element may implement a hardware implementation of the second portion of the graphical program.  
      The image acquisition device executing to perform the image processing function on the image may include the processor in the image acquisition device executing the first portion of the graphical program from the memory and the programmable hardware element executing the second portion of the graphical program.  
      The first and second portions of the graphical program may each include image processing portions. In some embodiments, the first portion of the graphical program may include an image processing portion, and the second portion of the graphical program may include a control portion. In other embodiments, the first portion of the graphical program may include the control portion, and the second portion of the graphical program may include the image processing portion.  
      In one embodiment, deploying the graphical program on the image acquisition device may include generating an executable program based on a first portion of the graphical program, and which implements functionality of the graphical program; transferring the executable program to the memory on the image acquisition device; generating a hardware description based on a second portion of the graphical program, where the hardware description describes a hardware implementation of the graphical program; and configuring the programmable hardware element in the image acquisition device utilizing the hardware description, where after being configured, the programmable hardware element implements a hardware implementation of the second portion of the graphical program. The image acquisition device executing to perform the image processing function on the image may include the processor in the image acquisition device executing the executable program from the memory and the programmable hardware element executing the second portion of the graphical program.  
      In one embodiment, the image acquisition device may include a first processor, a second processor, and at least one memory, and the image acquisition device executing to perform the image processing function on the image may include the first processor in the image acquisition device executing a first portion of the graphical program from the at least one memory and the second processor in the image acquisition device executing a second portion of the graphical program from the at least one memory. For example, the first portion of the graphical program may include a first portion of the image processing function, and the second portion of the graphical program may include a second portion of the image processing function.  
      During execution, a camera associated with the image acquisition device, or comprised in the smart camera, may acquire an image of an object. For example, the image acquisition device or smart camera may be used in a machine vision inspection application, or a manufacturing assembly application. The at least one functional unit in the image acquisition device or smart camera may then receive the acquired image of the object. The at least one functional unit in the image acquisition device or smart camera may then execute to perform the image processing function (or machine vision function) on the image. The results of this image processing may then be used to make a decision in a machine vision inspection application or may be used to perform an operation in a manufacturing assembly application. During execution of the at least one functional unit in the image acquisition device or smart camera, the user interface portion may be presented on a display. A user or operator may use the displayed user interface portion to view or control the image processing function (or machine vision function).  
      During operation, the image acquisition device may receive an image present signal, where the image acquisition device acquires the image of the object in response to receiving the image present signal. In another embodiment, the image acquisition device may perform a control operation after executing to perform the image processing function on the image. In yet another embodiment, the image acquisition device may generate a pass/fail indication after executing to perform the image processing function on the image. Alternatively, the image acquisition device may determine characteristics of the image after performing the image processing function, and then perform an operation based on the determined characteristics of the image.  
      In one embodiment, the image acquisition device may be coupled to a camera, and the image acquisition device acquiring an image of an object may include the camera acquiring the image of the object and the image acquisition device receiving and storing the image. Where the image acquisition device is a smart camera, the smart camera incorporates a camera as well as at least one functional unit.  
      In one embodiment the graphical program includes a user interface portion, and the method may include presenting the user interface portion on a display and/or receiving user input to the user interface portion on the display to control the image acquisition device, during the functional unit in the image acquisition device executing to perform the image processing function on the image. For example, the user interface portion may operate as a front panel for the image acquisition device.  
      In one embodiment, the method may further include compiling the user interface portion into executable code for execution by a processor and storing the executable code in a memory, and the processor executing the executable code from the memory to present the user interface portion on the display. The processor and memory may be included on the image acquisition device, and the processor in the image acquisition device may execute the executable code from the memory to present the user interface portion on the display during the image acquisition device executing to perform the image processing function on the image. In another embodiment, the processor and the memory may be included on the computer system, and the computer system may execute the executable code from the memory to present the user interface portion on the display during the image acquisition device executing to perform the image processing function on the image.  
      Thus the method may operate to configure an image acquisition device, such as an image acquisition board or smart camera, with a graphical program to perform image processing or machine vision functions, where the device includes a functional unit, such as a programmable hardware element or processor/memory.  
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
      A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:  
       FIG. 1  illustrates an image acquisition/machine vision system according to one embodiment of the invention;  
       FIG. 2A  illustrates a computer system coupled to a smart camera according to one embodiment of the invention;  
       FIG. 2B  illustrates a smart camera, according to one embodiment of the invention;  
       FIGS. 3A and 3B  illustrate image processing/machine vision systems according to embodiments of the invention;  
       FIG. 4  is a block diagram of the computer system of  FIGS. 1, 2A , and  3 A;  
       FIGS. 5A, 5B  and  5 C are block diagrams illustrating an interface card or device configured with a programmable hardware element and/or a processor and memory, according to various embodiments of the present invention;  
       FIGS. 6A-6C  are block diagrams illustrating a smart camera configured with a programmable hardware element and/or a processor and memory, according to various embodiments of the invention;  
       FIG. 7  is a flowchart diagram illustrating deployment of a graphical program on a device, according to one embodiment of the invention;  
       FIG. 8A  is a flowchart illustrating configuration of an image acquisition device or smart camera including a programmable hardware element, according to one embodiment of the invention;  
       FIG. 8B  is a flowchart illustrating configuration of an image acquisition device or smart camera including a processor and memory, according to one embodiment of the invention;  
       FIG. 9  illustrates the conversion of a graphical program to hardware and software implementations;  
       FIG. 10  illustrates the generation of various types of hardware and software descriptions from a VDiagram tree;  
       FIG. 11  illustrates the conversion of a graphical program into a hardware description and the use of the hardware description to program an FPGA;  
       FIG. 12  illustrates the conversion of a graphical program into a software source code description and the compilation and linkage of the source code;  
       FIG. 13  is a flowchart diagram illustrating operation of one embodiment of the invention, including compiling a first portion of the graphical program into machine language and converting a second portion of the graphical program into a hardware implementation; and  
       FIG. 14  is a flowchart diagram illustrating creation of a graphical program according to the preferred embodiment. 
    
    
      While the invention is susceptible to various modifications and alternative forms specific embodiments are shown by way of example in the drawings and will herein be described in detail. It should be understood however, that drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed. But on the contrary the invention is to cover all modifications, equivalents and alternative following within the spirit and scope of the present invention as defined by the appended claims.  
     DETAILED DESCRIPTION OF THE EMBODIMENTS  
     INCORPORATION BY REFERENCE  
      The following U.S. Patents and patent applications are hereby incorporated by reference in their entirety as though fully and completely set forth herein.  
      U.S. patent application Ser. No. 09/949,783 titled “System and Method for Deploying a Graphical Program on an Image Acquisition Device”, filed Sep. 10, 2001.  
      U.S. Pat. No. 4,914,568 titled “Graphical System for Modeling a Process and Associated Method,” issued on Apr. 3, 1990.  
      U.S. Pat. No. 6,219,628 titled “System and Method for Configuring an Instrument to Perform Measurement Functions Utilizing Conversion of Graphical Programs into Hardware Implementations”.  
      U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System” filed Aug. 18, 1997, whose inventors are Jeffrey L. Kodosky, Darshan Shah, Samson DeKey, and Steve Rogers.  
      U.S. patent application Ser. No. 09/499,503 titled “System and Method for Configuring a Programmable Hardware Instrument to Perform Measurement Functions Utilizing Estimation of the Hardware Implementation and Management of Hardware Resources”, filed on Feb. 7, 2000, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom, Cary Paul Butler, and Andrew Mihal.  
      U.S. patent application Ser. No. 09/891,571 titled “System and Method for Configuring an Instrument to Perform Measurement Functions Utilizing Conversion of Graphical Programs into Hardware Implementations” filed on Jun. 25, 2001, whose inventors are Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom, Cary Paul Butler, and Kevin L. Schultz.  
      U.S. patent application Ser. No. 09/745,023 titled “System and Method for Programmatically Generating a Graphical Program in Response to Program Information,” filed Dec. 20, 2000, whose inventors are Ram Kudukoli, Robert Dye, Paul F. Austin, Lothar Wenzel and Jeffrey L. Kodosky.  
      U.S. patent application Ser. No. 09/595,003 titled “System and Method for Automatically Generating a Graphical Program to Implement a Prototype”, filed Jun. 13, 2000, whose inventors are Nicolas Vazquez, Jeffrey L. Kodosky, Ram Kudukoli, Kevin L. Schultz, Dinesh Nair, and Christophe Caltagirone.  
      U.S. patent application Ser. No. 09/587,682 titled “System and Method for Automatically Generating a Graphical Program to Perform an Image Processing Algorithm”, filed on Jun. 5, 2000, whose inventors are Nicolas Vazquez, Jeffrey L. Kodosky, Ram Kudukoli, Kevin L. Schultz, Dinesh Nair and Christophe Caltagirone.  
      The LabVIEW and BridgeVIEW graphical programming manuals, including the “G Programming Reference Manual”, available from National Instruments Corporation, are also hereby incorporated by reference in their entirety.  
       FIG. 1 —Image Acquisition or Machine Vision System  
       FIG. 1  illustrates a host computer system  102  coupled to an image acquisition device  134 . As used herein, the term “image acquisition device” is intended to include any of various types of devices that are operable to acquire and/or store an image. An image acquisition device may also optionally be further operable to analyze or process the acquired or stored image. Examples of an image acquisition device include an image acquisition (or machine vision) card (also called a video capture board), a device external to a computer that operates similarly to an image acquisition card, a smart camera, a robot having machine vision, and other similar types of devices.  
      As used herein, the terms “image processing” and “machine vision” are used interchangeably to refer to the processing of images to extract useful information from the image or determine characteristics of the image (or to determine characteristics of one or more objects displayed in the image). The term “image processing” is used herein to refer to both “image processing” and “machine vision”, to the extent these terms have different meanings. The term “image processing function” includes tools such as edge detection, blob analysis, pattern matching, and other image processing functions. The term “image processing function” may also include an operation or decision that is performed in response to the information extracted or characteristics determined from the image. The term “image processing function” is also intended to include an image processing (or machine vision) algorithm that combines a sequence of two or more image processing functions or tools and/or decision operations that process an image in a desired way or which implement an image processing or machine vision application, such as part inspection, automated assembly, image analysis, pattern matching, edge detection, etc.  
      Thus,  FIG. 1  illustrates an exemplary image acquisition or machine vision system  100 . As  FIG. 1  shows, the image acquisition device  134  may in turn couple to or comprise a camera  132 . The image acquisition device  134  may include a functional unit for performing an image processing function as described below.  
      The host computer  102  may comprise a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer  102  may operate with the image acquisition device to analyze, measure or control a device or process  150 . Alternatively, the computer  102  may be used only to configure a functional unit in the image acquisition device.  
      As used herein, the term “functional unit” may include a processor and memory or a programmable hardware element. The term “functional unit” may include one or more processors and memories and/or one or more programmable hardware elements. As used herein, the term “processor” is intended to include any of types of processors, CPUs, microcontrollers, or other devices capable of executing software instructions. As used herein, the term “programmable hardware element” is intended to include various types of programmable hardware, reconfigurable hardware, programmable logic, or field-programmable devices (FPDs), such as one or more FPGAs (Field Programmable Gate Arrays), or one or more PLDs (Programmable Logic Devices), such as one or more Simple PLDs (SPLDs) or one or more Complex PLDs (CPLDs), or other types of programmable hardware.  
      As shown, video device or camera  132  may be coupled to the computer  102  via the image acquisition device or card  134 . The camera  132  and/or image acquisition device  134  may couple to the computer  102  through a serial bus, a network, or through other means.  
      The image acquisition system  100  may be used in an manufacturing assembly, test, measurement, and/or control application, among others. For illustration purposes, a unit under test (UUT)  150  is shown which may be positioned by a motion control device  136  (and interface card  138 ), and imaged and analyzed by the camera  132  and image acquisition device  134 . It is noted that in various other embodiments the UUT  150  may comprise a process or system to be measured and/or analyzed.  
      Referring again to  FIG. 1 , the computer  102  may include a memory medium on which computer programs, e.g., graphical programs, according to the present invention may be stored. As used herein, the term “memory medium” includes a non-volatile medium, e.g., a magnetic media or hard disk, or optical storage; a volatile medium, such as computer system memory, e.g., random access memory (RAM) such as DRAM, SRAM, EDO RAM, RAMBUS RAM, DR DRAM, etc.; or an installation medium, such as a CD-ROM or floppy disks  104 , on which the computer programs according to the present invention may be stored for loading into the computer system. The term “memory medium” may also include other types of memory or combinations thereof.  
      The memory medium may be comprised in the computer  102  where the programs are executed or may be located on a second computer which is coupled to the computer  102  through a network, such as a local area network (LAN), a wide area network (WAN), or the Internet. In this instance, the second computer operates to provide the program instructions through the network to the computer  102  for execution.  
      The software programs of the present invention may be stored in a memory medium of the respective computer  102 , or in a memory medium of another computer, and executed by the CPU. The CPU executing code and data from the memory medium thus comprises a means for deploying a graphical program onto an image acquisition device, e.g., a smart camera, according to the steps described below.  
      The memory medium may store a graphical programming development system for developing graphical programs. The memory medium may also store one or more computer programs which are executable to deploy a graphical program, such as by converting at least a portion of a graphical program into a form for configuring or programming a programmable hardware element, by executing the graphical program natively on a processor, or by converting the graphical program to a different form for execution by a processor and memory. The image acquisition device  134  in  FIG. 1  may be controlled by or configured by graphical software programs which are deployed or downloaded to the functional unit on the device  134 .  
      As described below, in one embodiment the graphical program may be deployed by either one or more of: 1) converting the graphical program (or a portion thereof) into a hardware implementation and configuring the programmable hardware element with this hardware implementation, 2) transferring the graphical program (or a portion thereof) to a memory of the functional unit for execution by a processor (wherein the processor may execute a graphical program execution engine and optionally a real time operating system), or 3) compiling the graphical program (or a portion thereof) into an executable program and transferring the executable program to a memory of the functional unit for execution by a processor (wherein the processor may optionally execute a real time operating system).  
      In the present application, the term “graphical program” or “block diagram” is intended to include a program comprising graphical code, e.g., two or more nodes or icons interconnected in one or more of a data flow, control flow, or execution flow format, where the interconnected nodes or icons may visually indicates the functionality of the program. Thus the terms “graphical program” or “block diagram” are each intended to include a program comprising a plurality of interconnected nodes or icons which visually indicates the functionality of the program. A graphical program may comprise a block diagram and may also include a user interface portion or front panel portion. The user interface portion may be contained in the block diagram or may be contained in one or more separate panels or windows. A graphical program may be created using any of various types of systems which are used to develop or create graphical code or graphical programs, including LabVIEW, DASYLab, and DiaDem from National Instruments, Visual Designer from Intelligent Instrumentation, Agilent VEE (Visual Engineering Environment), Snap-Master by HEM Data Corporation, SoftWIRE from Measurement Computing, ObjectBench by SES (Scientific and Engineering Software), Simulink from the MathWorks, WiT from Coreco, Vision Program Manager from PPT Vision, Hypersignal, VisiDAQ, Vis Sim, and Khoros, among others. In the preferred embodiment, the system uses the LabVIEW graphical programming system available from National Instruments.  
      FIGS.  2 A and  2 B—Image Acquisition System Having a Smart Camera  
       FIGS. 2A and 2B  illustrate an image acquisition system with a smart camera. As  FIGS. 2A and 2B  illustrate, a smart camera may include a housing which encloses a portion or all of the smart camera components, or may be comprised on a frame which primarily provides structural support for the smart camera components.  
       FIG. 2A —Image Acquisition System with Smart Camera  
       FIG. 2A  illustrates an image acquisition system comprising computer system  102  coupled to a smart camera  190 . The smart camera is an example of an image acquisition device. As used herein, the term “smart camera” is intended to include any of various types of devices that include a camera or other image sensor and a functional unit capable of being configured to perform an image processing function to analyze or process an acquired image. For example, while traditional computer vision is based on a camera/computer system in which the image processing or understanding algorithm is embedded in the computer  102 , the computational load of vision algorithms may be circumvented or mitigated by merging low level processing with the camera or sensor in a single module. For example, a hardware architecture may be defined in a Hardware Description Language (e.g., VHDL), simulated and synthesized into digital structures that can then be configured in a Field Programmable Gate Array (FPGA). In one application of a smart camera, the flexibility of an FPGA may be combined with a sensor for real time image processing. In another application of a smart camera, the flexibility of a processor and memory may be combined with a sensor for real time image processing. Examples of smart cameras include: NAVSYS Corporation&#39;s GI-EYE, which generates digital image data that are automatically tagged with geo-registration meta-data to indicate the precise position and attitude of the camera when the image was taken; Vision Components&#39; GmbH Smart Machine Vision Cameras, which integrate a high-resolution Charge Coupled Device (CCD) sensor with a fast image-processing signal processor, and provide various interfaces to allow communication with the outside world; and Visual Inspection Systems&#39; SMART cameras with on-board DSP capabilities, including frame grabbers and robot guidance systems, among others.  
      The computer system  102  shown in  FIG. 2A  may include a memory medium. As noted above, the memory medium may store a graphical programming development system for developing graphical programs. The graphical programming development system may be used to develop a graphical program that implements an image processing function. In this example, one or more of the nodes in the graphical program may implement or represent an image processing function.  
      The memory medium may also store one or more computer programs which are executable to convert at least a portion of a graphical program into a form for configuring a functional unit comprised in the smart camera  190 .  
      As mentioned above, the smart camera  190  may include a functional unit, which may be a programmable hardware element (programmable or reconfigurable hardware), e.g., an FPGA, and/or may be a processor and memory. The functional unit in the smart camera  190  may be configured with a graphical program that implements the image processing function. The smart camera  190  may also comprise a camera coupled to the functional unit. The smart camera  190  may also include a memory (a memory medium) coupled to the camera that stores an acquired image. If the smart camera  190  includes an analog camera, the smart camera  190  may further include analog to digital (A/D) logic for converting analog image signals into a digital image for storage in the memory. The smart camera  190  may also optionally include timer/counter logic that may perform timing/counting operations, e.g., during operation of the functional unit. As  FIG. 2A  shows, in one embodiment, the smart camera may include a housing which encloses some or all of the components of the smart camera. Various embodiments of the smart camera  190  are shown in  FIGS. 6A-6D , described below.  
       FIG. 2B —Smart Camera  
       FIG. 2B  illustrates another embodiment of a smart camera  190 . As  FIG. 2B  shows, the smart camera includes a camera, coupled to circuitry/logic (e.g., one or more circuit boards) for performing various image processing and/or acquisition functions. As mentioned above, the circuitry/logic may include a functional unit, such as a programmable hardware element, e.g., an FPGA and/or a processor and memory. As also described above, the functional unit in the smart camera  190  may be configured with a graphical program that implements the image processing function, and may also include a memory coupled to the camera for storing an acquired image. If the camera is an analog camera, the smart camera  190  may further include analog to digital (A/D) logic for converting analog image signals into a digital image for storage in the memory. The smart camera  190  may also optionally include timer/counter logic that may perform timing/counting operations, e.g., during operation of the programmable hardware element. The smart camera  190  may also include various I/O ports for communicating with external devices, such as computer system  102 . As  FIG. 2B  shows, in one embodiment, the smart camera may include a frame or structure to support the components comprised in the smart camera. In one embodiment, the smart camera may include a “PC-on-a-Card” which may provide part or all of the functionality of a personal computer. Various embodiments of the smart camera  190  are shown in  FIGS. 6A-6D , described below.  
      FIGS.  3 A and  3 B—Image Processing Systems  
       FIGS. 3A and 3B  illustrate image processing or machine vision systems according to various embodiments of the invention. The image processing system of  FIG. 3A  may comprise a computer  102  and a smart camera  190 , and may further include a motion control device  192 . The image processing system of  FIG. 3B  may comprise smart camera  190  and motion control device  192 , and may not include computer system  102 .  
      The smart camera  190  may include a digital camera that acquires a digital video signal which comprises an image, or a sequence of images, or other data desired to be acquired. In one embodiment, the smart camera  190  may instead include an analog camera that acquires an analog video signal, and the smart camera  190  may further include A/D converters for converting the analog video signal into a digital image.  
      The smart camera  190  may include a functional unit configured according to a graphical program. For example, the functional unit may be configured to perform an image processing function as represented by a graphical program. Thus a graphical program may have been first created to perform the image processing function, such as with a graphical development environment on the computer system  102 , and the graphical program may then have been deployed onto the functional unit of the smart camera to implement the image processing function.  
      In the machine vision system of  FIG. 3A , the digital video signal or digital image may be provided to the functional unit in the smart camera  190 , wherein the image processing function is performed.  
      In the embodiment of  FIG. 3A , the functional unit in the smart camera  190  may perform a portion or all of the image processing function, and the computer  102  may perform a portion of the image processing function. For example, the functional unit in the smart camera  190  may perform the actual processing of the image to determine characteristics of the image, and the computer  102  may then perform an operation based on this result, such as rejecting a part from an assembly line, or logging the results to file. As another example, the functional unit in the smart camera  190  may perform the processing of the image to determine characteristics of the image, and may also optionally perform an operation based on this result, and the computer system  102  may execute software to provide a user interface for the system, e.g., the computer system  102  may execute a user interface portion of a graphical program, where the block diagram of the graphical program is used to configure the functional unit in the smart camera  190 . Thus, in one embodiment, a first portion of the graphical program, e.g., DSP functions requiring real time performance, may be executed by the smart camera, i.e., the functional unit, and a second portion of the graphical program, e.g., a user interface where real time performance is not required, may be executed by the computer system  102 .  
      In the embodiment of  FIG. 3B , the functional unit in the smart camera  190  may perform all of the desired image processing function, including optionally performing an operation based on determined characteristics of the image, and hence the computer system  102  is not necessary during operation of the system. In another embodiment, the smart camera  190  may include a processor and memory (in addition to the functional unit which executes the image processing function) which may execute the second portion of the graphical program, e.g., the user interface portion.  
      In the embodiments of  FIGS. 3A and 3B , the functional unit in the smart camera  190  (or the computer system  102  in  FIG. 3A ) may control the motion control device  192 . In an alternate embodiment, the motion control device  192  may also include a functional unit that has been configured with a graphical program. The functional unit in the motion control device  192  may be configured to perform a motion control function. Thus a graphical program may have been first created that performs the motion control function, and the graphical program may then have been deployed onto the motion control device  192  as described herein. Examples of motion control functions include moving a part or object to be imaged by a camera, rejecting a part on an assembly line, or placing or affixing components on a part being assembled, or a robotics application, among others.  
       FIG. 4 —Computer Block Diagram  
       FIG. 4  is an exemplary block diagram of the computer  102  of  FIGS. 1, 2A , and  3 A. The elements of a computer not necessary to understand the operation of the present invention have been omitted for simplicity. The computer  102  may include at least one central processing unit (CPU) or processor  160  which is coupled to a processor or host bus  162 . The CPU  160  may be any of various types, including an x86 processor, a PowerPC processor, a CPU from the Motorola family of processors, a CPU from the SPARC family of RISC processors, as well as others. Main memory  166  is coupled to the host bus  162  by means of memory controller  164 . The main memory  166  stores a graphical programming system, and also stores software for deploying at least a portion of a graphical program onto an image acquisition device  134 . This software will be discussed in more detail below. The main memory  166  may also store operating system software, i.e., software for operation of the computer system, as well as one or more application programs, as is well known to those skilled in the art.  
      The host bus  162  is coupled to an expansion or input/output bus  170  by means of a bus controller  168  or bus bridge logic. The expansion bus  170  is preferably the PCI (Peripheral Component Interconnect) expansion bus, although other bus types may be used. The expansion bus  170  may include slots for various devices, the examples shown including a motion control device  138  and an image acquisition device  134 , as described above in reference to  FIG. 1 . The computer  102  may further comprise a video display subsystem  180  and hard drive  182  coupled to the expansion bus  170 , also shown.  
      One or more of the interface cards or devices (e.g., those shown in  FIGS. 1, 2A ,  2 B,  3 A and/or  3 B) may be coupled to or comprised in the computer  102  and may comprise a functional unit, such as a programmable hardware element (FPGA) and/or processor and memory. The computer  102  may also include a network interface for coupling to a network, wherein the target device containing the functional unit may be coupled to the network. Thus the computer  102  may be used for configuring a functional unit hardware in a target device over a network.  
      FIGS.  5 A- 5 D—Image Acquisition Device Hardware Diagram  
       FIG. 5A  is a block diagram illustrating a device, e.g., an interface card  134 A, configured with programmable hardware according to one embodiment. It is noted that  FIG. 5A  is exemplary only, and an interface card or device configured with programmable hardware according to the present invention may have various architectures or forms, as desired. For example, the device may be internal or external to the computer  102 , and may be connected to the computer through a network, such as the Internet. The interface card  134 A illustrated in  FIG. 5A  may be the image acquisition device  134  or the motion control interface card  138 , shown in  FIGS. 1-3 .  
      As shown in  FIG. 5A , the interface card  134 A may include an I/O connector  202  which is operable to send/receive signals. The I/O connector  202  may present analog and/or digital connections for receiving/providing analog or digital signals, such as image signals or pixel data. In one embodiment, the I/O connector  202  may be adapted for coupling to an external camera.  
      The interface card  134 A may also include data acquisition (DAQ) logic  204 . As shown, the data acquisition logic  204  may comprise analog to digital (A/D) converters, digital to analog (D/A) converters, timer counters (TC) and signal conditioning (SC) logic as shown. The DAQ logic  204  may provide data acquisition functionality of the image acquisition card  134 A. In one embodiment, the DAQ logic  204  comprises 4 A/D converters, 4 D/A converters,  23  digital I/Os, a RTSI connector, and a TIO. This extra hardware is useful for signal processing and motion control applications. The functional unit, e.g., programmable hardware element or FPGA  206  and/or processor  212  may access these resources directly, thereby enabling creation of very image processing applications, among others.  
      In the embodiment of  FIG. 5A , the functional unit of the interface card  134 A may include a programmable hardware element  206  and a processor  212  and memory  214 . In one embodiment, the programmable hardware  206  may comprise a field programmable gate array (FPGA) such as those available from Xilinx, Altera, etc. The programmable hardware element  206  may be coupled to the DAQ logic  204  and may also be coupled to a local bus interface  208 , described below. Thus a graphical program can be created on the computer  102 , or on another computer in a networked system, and at least a portion of the graphical program can be converted into a hardware implementation form for execution in the FPGA  206 . The portion of the graphical program converted into a hardware implementation form is preferably a portion which requires fast and/or real time execution.  
      In the embodiment of  FIG. 5A , the interface card  134 A may further include a dedicated on-board processor  212  and memory  214 . This enables a portion of the graphical program to be compiled into machine language for storage in the memory  214  and execution by the processor  212 . A portion of the graphical program may also (or instead) be transferred to the memory  214  in its native format for execution by the processor. This may be in addition to a portion of the graphical program being converted into a hardware implementation form in the FPGA  206 . The memory  214  may store a real time operating system (RTOS) for execution by the processor  212 . Where the graphical program executes in its native format on the device  134 A, the memory may also store a graphical program execution engine that is executed by the processor  212 .  
      Thus, in one embodiment, after a graphical program has been created, a portion of the graphical program may be transferred and/or compiled for execution on the on-board processor  212  and executed locally on the interface card  134 A via the processor  212  and memory  214 , and a second portion of the graphical program may be translated or converted into a hardware executable format and downloaded to the FPGA  206  for hardware implementation.  
      As mentioned above, as one example, a first portion of a block diagram (that requires real time or fast execution) of a graphical program may be converted into a hardware executable format and downloaded to the FPGA  206  for hardware implementation, and a second portion of a block diagram (that may not require real time performance) may be stored in the memory  214  as program instructions and executed by the processor  212 , in either a compiled or interpreted manner. As another example, a portion or all of the block diagram portion of the graphical program may be converted into a hardware executable format and downloaded to the FPGA  206  for hardware implementation, and a user interface portion (or front panel portion) of the graphical program may be stored in the memory  214  as program instructions and executed by the processor  212 , in either a compiled or interpreted manner. Thus the portion of the graphical program which requires the most real time or deterministic (reliable and consistent) performance may be executed directly in hardware for fast operation, and other parts of the block diagram, or the user interface portion, which may not require real time performance, may execute on the processor  212 . Where the processor executes the user interface portion, the processor may then send resulting signals to the video subsystem for display of the user interface on the computer display.  
      As shown, the interface card  134 A may further include bus interface logic  216  and a control/data bus  218 . In one embodiment, the interface card  134 A is a PCI bus-compliant interface card adapted for coupling to the PCI bus of the host computer  102 , or adapted for coupling to a PXI (PCI extensions for Instrumentation) bus. The bus interface logic  216  and the control/data bus  218  thus present a PCI or PXI interface.  
      The interface card  134 A may also include local bus interface logic  208 . In one embodiment, the local bus interface logic  208  may present a RTSI (Real Time System Integration) bus for routing timing and trigger signals between the interface card  134 A and one or more other devices or cards, such as a motion device.  
      In one embodiment, the interface card  134 A also includes a non-volatile memory  288  coupled to the programmable hardware element  206 , the processor  212  and the memory  214 . The non-volatile memory  288  may be operable to store the hardware description received from the host computer system to enable execution of the hardware description in the programmable hardware element  206  prior to or during booting of the computer system  102 . The non-volatile memory  288  may also store software used by the processor, such as a RTOS and/or a graphical program execution engine.  
      In the embodiment of  FIG. 5B , the programmable hardware element  206  is not included on the interface card  134 B, and thus the functional unit of the device  134 B comprises only processor  212  and memory  214 . Thus, in deploying the graphical program, a portion or all of the graphical program which is to be deployed may be transferred to the memory  214  for execution by the processor  212 . The graphical program may be transferred in its native format to the memory  214  and executed by the processor  212  using a graphical program execution engine and possibly a RTOS. Alternatively, the graphical program may be compiled into an executable program (e.g., machine language, a script, or an interpretable data structure) and transferred to the memory  214  for execution by processor  212 .  
      In the embodiment of  FIG. 5C , the processor  212  is not included on the interface card  134 C, i.e., the functional unit of the device  134 C comprises the FPGA  206  and the memory  214 . In this embodiment, the memory  214  may be used for storing FPGA state information. Thus in the embodiment of  FIG. 5C , any supervisory control portion of the graphical program which is necessary or desired to execute on a programmable processor in software may be executed by the host CPU in the computer system  102 , and is not executed locally by a processor on the interface card  134 B.  
      FIGS.  6 A- 6 C—Block Diagrams of Smart Cameras with Programmable Hardware  
       FIGS. 6A-6C  are block diagrams of various embodiments of a smart camera  190  with programmable hardware. As may be seen, the various embodiments share a number of features and configurations with the various interface cards  134  described above with reference to  FIGS. 5A-5C , specifically the use of various combinations of processor/memory elements and programmable hardware, e.g., FPGAs, to execute portions of a graphical program. It should be noted that these embodiments are meant to be illustrative only, and are not intended to limit the architecture, components, or form of the smart camera  190 .  
       FIG. 6A  illustrates one embodiment of a smart camera  190  which includes a camera  282  and a functional unit. In this embodiment, the functional unit may comprise a programmable hardware element  206 , e.g., a field programmable gate array (FPGA) such as those available from Xilinx, Altera, etc, and may also comprise a processor  212  and memory  214 . Each of the programmable hardware element  206 , processor  212  and memory  214  may be coupled to the camera  282  and/or to an image memory  284 .  
      As shown, the smart camera  190 A may also include a non-volatile memory  288  coupled to the programmable hardware element  206 , the processor  212 , the memory  214  and the image memory  284 . The non-volatile memory  288  may be operable to store the hardware description and/or graphical program received from the host computer system to enable execution of the functional unit prior to or during booting of the computer system  102 .  
      Although not shown, the smart camera  190  may include an I/O connector  202  which is operable to send and receive signals. The I/O connector  202  may present analog and/or digital connections for receiving/providing analog or digital signals. For example the I/O connector  202  may enable the smart camera to communicate with computer system  102  to receive a graphical program for performing image processing functions. Thus a graphical program can be created on the computer  102 , or on another computer in a networked system, and at least a portion of the graphical program can be deployed onto a functional unit of the smart camera. The portion of the graphical program converted into a hardware implementation form is preferably a portion which requires fast and/or real-time execution.  
      As noted above, the smart camera  190 A includes a dedicated on-board processor  212  and memory  214  in addition to the programmable hardware element  206 . This enables a portion of the graphical program to be compiled into machine language for storage in the memory  214  and execution by the processor  212  (or to execute natively). This is in addition to a portion of the graphical program being converted into a hardware implementation form in the FPGA  206 . Thus, in one embodiment, after a graphical program has been created, a portion of the graphical program may be compiled for execution on the on-board processor  212  and executed locally on the smart camera  190 A via the processor  212  and memory  214 , and a second portion of the graphical program may be translated or converted into a hardware executable format and uploaded to the FPGA  206  for hardware implementation.  
      For example, in a manner similar to that described above with reference to  FIG. 5A , a first portion of a block diagram (that requires real time or fast execution) of a graphical program, e.g., a graphical image processing program, may be converted into a hardware executable format and downloaded to the FPGA  206  for hardware implementation, and a second portion of a block diagram (that may or may not require real time performance) may be stored in the memory  214  as program instructions and executed by the processor  212 , in either a compiled or interpreted manner. As another example, a portion or all of the block diagram portion of the graphical program may be converted into a hardware executable format and downloaded to the FPGA  206  for hardware implementation, and a user interface portion (or front panel portion) of the graphical program may be downloaded and stored in the memory  214  as program instructions and executed by the processor  212 , in either a compiled or interpreted manner. Thus the portion of the graphical program which requires the most real time or deterministic (reliable and consistent) performance may be executed directly in hardware for fast operation, and other parts of the block diagram, or the user interface portion, which may not require real time performance, may execute on the processor  212 . Where the processor executes the user interface portion, the processor may then send resulting signals to a video subsystem (of, for example, the computer system  102 ) for display of the user interface on the computer display.  
      As noted above the smart camera  190 A may include image memory  284  which couples to the programmable hardware  206 , the camera  282 , the processor  212 , memory  214 , bus interface  216 , and the control/data bus  218 . The image memory  284  may be operable to store a portion of an image, or one or more images received from the camera  282 . The image memory  284  may enable the programmable hardware  206  and/or the processor  212  to retrieve the one or more images, operate on them, and return the modified images to the image memory. Additionally, the images may be retrievable for transmission to external systems, such as the computer system  102 , via the I/O connector  202 , for example.  
      As shown, the smart camera  190 A may further include bus interface logic  216  and a control/data bus  218 . In one embodiment, the smart camera  190 A is a PCI bus-compliant interface card adapted for coupling to the PCI bus of the host computer  102 , or adapted for coupling to a PXI (PCI eXtensions for Instrumentation) bus. The bus interface logic  216  and the control/data bus  218  thus present a PCI or PXI interface.  
      Although not shown, in one embodiment, the smart camera  190 A may also include local bus interface logic  208 , as shown in  FIG. 5A . In one embodiment, the local bus interface logic  208  may present a RTSI (Real Time System Integration) bus for routing timing and trigger signals between the smart camera  190 A and one or more other devices or cards, such as other smart camera, motion devices, or other smart sensors.  
      In yet another embodiment, the smart camera  190 A may include data acquisition (DAQ) logic  204 , not shown, such as analog to digital (A/D) converters, digital to analog (D/A) converters, timer counters (TC) and signal conditioning (SC) logic, as shown in  FIG. 5A . The DAQ logic  204  may be useful for signal processing and motion control applications. The programmable hardware element or FPGA  206  may access these resources directly, thereby enabling creation of very powerful measurement, DSP and control applications, among others. For example, if the camera  282  is an analog camera, the smart camera  190 A may further include analog to digital (A/D) logic (not shown) for converting analog image signals into a digital image for storage in the memory.  
       FIG. 6B  illustrates another embodiment of a smart camera  190 B, with a configuration similar to that of interface card  134 B, described above with reference to  FIG. 5B . As  FIG. 6B  shows, in this embodiment, the smart camera  190 B includes the camera  282 , processor  212 , memory  214 , image memory  284 , control/data bus  218 , and bus interface  216  described above with reference to  FIG. 6A , but does not include the programmable hardware (e.g., FPGA). Thus, in this embodiment the functional unit comprises only the processor  212  and memory  214 . Thus a portion or all of a graphical program may be deployed to the processor/memory component  212 / 214 . As  FIG. 6B  also shows, timer/counter logic  286  may also be included on the smart camera. The timer/counter logic  286  may be coupled to the other components of the smart camera  190 B, and may be operable to provide high-performance timing and counting functions to the various elements of the smart camera  190 B. For example, in one embodiment, the timer/counter logic may be used by the processor  212  to accurately control image acquisition by the camera  282 , such as for a high speed assembly line, or for capturing images of a fast-moving object.  
       FIG. 6C  illustrates another embodiment of a smart camera  190 C, where the smart camera  190 C includes programmable hardware  206  and non-volatile memory  288 , but does not include the processor  212  and memory  214 . Thus in the embodiment of  FIG. 6C  the functional unit comprises only the FPGA  206 . Thus, any supervisory control portion of the graphical program which is necessary or desired to execute on a programmable processor in software may be executed by the host CPU in the computer system  102 , and is not executed locally by processor  212 , i.e., on the smart camera  190 C. As  FIG. 6C  also shows, the smart camera may include camera  282 , bus interface  216 , control/data bus  218 , image memory  284 , and timer/counter logic  286 , as described above. Thus, a graphical image processing program, in the form of a hardware description, may be converted into a hardware executable format and downloaded to the programmable hardware element  206  for hardware implementation. Note that, as described above, the non-volatile memory  288  (or a separate volatile memory not shown) may be operable to store the hardware description received from the host computer system  102  to enable execution of the hardware description in the programmable hardware element  206  prior to or during booting of the computer system  102 .  
       FIG. 7 —Method for Deploying a Graphical Program on an Image Acquisition Device  
       FIG. 7  illustrates one embodiment of a method for deploying a graphical program on an image acquisition device to perform an image processing function, where the image acquisition device includes a functional unit. Said another way, a computer-implemented method is presented for configuring an image acquisition device to perform an image processing function using a graphical program. Note that the method shown in  FIG. 7  may be used to configure any of the instruments or devices shown in  FIGS. 1-6D . It should be noted that in various embodiments, various steps in the method may occur concurrently, or in a different order than shown. Additionally, some steps may be omitted, or additional steps performed which are not shown, as desired. As shown, this method may operate as follows.  
      In step  702  a graphical program may be created that implements an image processing function. In the preferred embodiment, the graphical program is created on the computer system  102 , although in other embodiments the graphical program may be created on a different computer system, for example, coupled to computer system  102  over a network. The graphical program may be created or assembled by the user with a graphical programming environment, such as the LabVIEW graphical programming development environment. In an alternate embodiment, the graphical program may be created in step  702  by the user specifying one or more functions or tasks, after which the specification may be analyzed and the graphical program generated automatically or programmatically from the specification. For example, the user may use a prototyping environment to create a script or prototype representing an image processing algorithm, and then a graphical program may be manually or programmatically created based on this prototype. It is noted that other approaches may also be used to create the graphical program, either manually by the user, or programmatically by software.  
      In step  704  the graphical program may be deployed on the image acquisition device  134 . Note that in the preferred embodiment, the image acquisition device  134  is coupled to the computer system  102  to facilitate the deployment of the graphical program. In one embodiment, the image acquisition device  134  may be comprised in the computer system  102 . In other embodiments the image acquisition device  134  may be coupled to the computer system  102  through a network, such as the Internet, or may be coupled to the computer system  102  through wireless means. In another embodiment, a human user may manually retrieve the graphical program from the computer  102  and load the graphical program onto the image acquisition device  134 . As described in more detail below, deploying the graphical program on the image acquisition device  134  may comprise storing the graphical program on (at least part of) the functional unit, or configuring the functional unit with all or part of the graphical program, such that after the deployment, the functional unit is operable to execute or implement the functionality of the graphical program.  
      In step  706 , the image acquisition device  134  may acquire an image of an object, such as, for example, the UUT  150 , or an element or state of a system or process. In the preferred embodiment, the image is acquired via camera  132 , although in other embodiments the image may be acquired from an external system, such as a computer or another image acquisition device. In one embodiment, the image acquisition device  134  may receive an image present signal, and acquire the image of the object in response to receiving the image present signal. In one embodiment, the image acquisition device may be coupled to a camera, and the image acquisition device acquiring an image of the object may comprise the camera acquiring the image of the object and the image acquisition device receiving and storing the image.  
      Finally, in step  708 , the image acquisition device may execute to perform the image processing function on the acquired image from  706 . In other words, the functional unit on the image acquisition device  134  may execute all or part of the graphical program. For example, the image processing function may operate to analyze the image and detect, recognize, or characterize one or more features or characteristics of the object, such as position, orientation, color, or possible flaws or lack thereof, among others. In one embodiment, the image acquisition device may perform a control operation after executing to perform the image processing function on the image. In another embodiment, the image acquisition device may generate a pass/fail indication after executing to perform the image processing function on the image. In another embodiment, the image acquisition device executing to perform the image processing function on the acquired image may comprise the image acquisition device determining characteristics of the image after performing the image processing function, and the image acquisition device  134  performing an operation based on the determined characteristics of the image.  
      For example, in a quality control system in an automated assembly plant, in performing the image processing function on the acquired image, the image acquisition device may determine a characteristic of the image indicating that the imaged object is defective. The image acquisition device  134  may then send a signal, such as a pass/fail indication, to a motion control device which may remove the defective object from the assembly line. An example of such a system is described above with reference to  FIGS. 3A and 3B .  
      In one embodiment, the image acquisition device  134  may include processor  212  and memory  214 , as described above with reference to  FIGS. 5B and 6B . The deployment of the graphical program on the image acquisition device  134  described in  704  may then comprise transferring the graphical program to the memory  214  on the image acquisition device  134 .  
      In one embodiment, deploying the graphical program on the image acquisition device  134  may include generating an executable program (a machine language program) based on the graphical program, which implements the functionality of the graphical program, and transferring the executable program to the memory  214  on the image acquisition device. In this embodiment, the image acquisition device executing to perform the image processing function on the image in  708  may comprise the processor  212  in the image acquisition device  134  executing the executable program from the memory  214 , possibly by executing a real time operating system (RTOS) from the memory  214 . In the case where the executable program is generated from the graphical program, the image acquisition device executing to perform the image processing function on the image may comprise the processor in the image acquisition device executing the executable program (in executable form) from the memory  214 .  
      In another embodiment, deploying the graphical program on the image acquisition device  134  may include transferring the graphical program in its native or original format to the memory  214  on the image acquisition device. In this embodiment, the image acquisition device executing to perform the image processing function on the image in  708  may comprise the processor  212  in the image acquisition device  134  executing a graphical program execution engine, and possibly a real time operating system (RTOS) from the memory  214 .  
      In another embodiment, the image acquisition device may include a programmable hardware element  206 , such as an FPGA, as described above with reference to  FIGS. 5C and 6C . The deployment of the graphical program on the image acquisition device  134  described in  704  may then comprise generating a hardware description based on the graphical program, which describes a hardware implementation of the graphical program, and configuring the programmable hardware element  206  in the image acquisition device  134  utilizing the hardware description. Configuring the programmable hardware element  206  in the image acquisition device  134  utilizing the hardware description may comprise converting the hardware description, such as a VHDL file, into a netlist using available synthesis tools, and the compiling the netlist into a hardware program file (also called a software bit stream), which may be used to configure or program the programmable hardware element  206 .  
      After configuring the programmable hardware element  206  with the hardware description, the programmable hardware  206  implements a hardware implementation of the graphical program. In this embodiment, the image acquisition device executing to perform the image processing function on the image in  708  may comprise the programmable hardware element  206  in the image acquisition device executing to perform the image processing function on the image.  
      In yet another embodiment, the image acquisition device may include the processor  212  and memory  214  and the programmable hardware element  206 , as described above with reference to  FIGS. 5A, 6A , and  6 D. The deployment of the graphical program on the image acquisition device  134  described in  704  may then comprise transferring a first portion of the graphical program to the memory  214  on the image acquisition device  134  (either in native or compiled form), generating a hardware description based on a second portion of the graphical program describing a hardware implementation of the graphical program, and configuring the programmable hardware element in the image acquisition device utilizing the hardware description, after which the programmable hardware element implements a hardware implementation of the second portion of the graphical program. This embodiment of the invention may be referred to as a “dual mode” embodiment. In this embodiment, the image acquisition device executing to perform the image processing function on the image in  708  may comprise the processor  212  in the image acquisition device  134  executing the first portion of the graphical program from the memory  214  and the programmable hardware element  206  executing the second portion of the graphical program.  
      In an exemplary dual mode embodiment, the deployment may include generating an executable program based on the first portion of the graphical program, which implements the functionality of the first portion of the graphical program, and transferring the executable program to the memory  214  on the image acquisition device. The second portion may be configured on the programmable hardware element.  
      In one embodiment, the first portion of the graphical program may comprise an image processing portion, and the second portion of the graphical program may comprise a control portion. In another embodiment, the first portion of the graphical program may comprise a control portion, and the second portion of the graphical program may comprise an image processing portion. In this embodiment, the image acquisition device executing to perform the image processing function on the image in  708  may comprise the processor  212  in the image acquisition device  134  executing the executable program from the memory  214  to implement the first portion and the programmable hardware element  206  executing the second portion of the graphical program.  
      In yet another embodiment of the present invention, the image acquisition device  134  may include a first processor  212 A, a second processor  212 B, and at least one memory  214 . In this case, the image acquisition device executing to perform the image processing function on the image may comprise the first processor  212 A in the image acquisition device  134  executing a first portion of the graphical program from the at least one memory  214  and the second processor  212 B in the image acquisition device  134  executing a second portion of the graphical program from the at least one memory  214 . Note that in this case, both the first portion and the second portion of the graphical program are executable by a processor from memory. For example, the first portion of the graphical program may comprise an image processing portion, and the second portion of the graphical program may comprise a control portion. In another embodiment, the first portion of the graphical program may comprise a first portion of the image processing function, and the second portion of the graphical program may comprise a second portion of the image processing function. Alternatively, the functional unit may comprise two or more programmable hardware elements which operate as above.  
      In one embodiment, the image acquisition device may comprise a smart camera, such as described above with reference to  FIG. 2B , and FIGS.  6 A-C. In another embodiment, the image acquisition device may comprise an image acquisition board coupled to or comprised in a computer system, as shown in  FIG. 2A , and FIGS.  5 A-C.  
      More detailed embodiments of this method are presented below with reference to  FIGS. 8A and 8B .  
       FIG. 8A —Configuring an Image Acquisition Device or Smart Camera Including Programmable Hardware to Perform an Image Processing Function  
       FIG. 8A  is an exemplary embodiment illustrating a method for configuring an image acquisition device  134 , such as smart camera  190 , with a graphical program to perform an image processing function, where the image acquisition device  134  (or smart camera  190 ) includes a functional unit, more specifically, a programmable hardware element  206 . The method shown in  FIG. 8A  is a more detailed version of the method of  FIG. 7  described above, wherein the method is described with reference to an image acquisition device or smart camera. It should be noted that in various embodiments, various steps in the method may occur concurrently, or in a different order than shown. Additionally, some steps may be omitted, or additional steps performed which are not shown, as desired. As shown, this method may operate as follows.  
      First, in step  862  a graphical program may be created on the computer system  102  (or on a different computer system). The graphical program may be created or assembled by the user arranging on a display a plurality of nodes or icons and then interconnecting the nodes to create the graphical program. In response to the user assembling the graphical program, data structures (and/or program instructions) may be created and stored which represent the graphical program. The nodes may be interconnected in one or more of a data flow, control flow, or execution flow format. The graphical program may thus comprise a plurality of interconnected nodes or icons which visually indicates the functionality of the program. As noted above, the graphical program may comprise a block diagram and may also include a user interface portion or front panel portion. Where the graphical program includes a user interface portion, the user may assemble the user interface on the display. As one example, the user may use the LabVIEW graphical programming development environment to create the graphical program.  
      In an alternate embodiment, the graphical program may be created in step  862  by the user creating or specifying a prototype, followed by automatic or programmatic creation of the graphical program from the prototype. This functionality is described in U.S. patent application Ser. No. 09/587,682 titled “System and Method for Automatically Generating a Graphical Program to Perform an Image Processing Algorithm”, incorporated by reference above. The graphical program may be created in other manners, either by the user or programmatically, as desired. In the present example where the instrument is an image acquisition device  134  (e.g., smart camera  190 ), the graphical program may implement an image processing function.  
      In step  864  the image acquisition device  134  (e.g., smart camera  190 ) may be coupled to the computer system  102 . The image acquisition device  134  (e.g., smart camera  190 ) may be coupled to the computer system  102  over a network, via communication cable(s), through wireless means, or by any other method of coupling, as desired. As noted above, the smart camera  190  may comprise a camera and a programmable hardware element  206 . It is noted that the image acquisition device may be connected to the computer system  102  before, during or after the graphical program is created.  
      In step  866  a hardware configuration based on the graphical program may be downloaded onto the programmable hardware element  206  in the image acquisition device  134  (e.g., smart camera  190 ) to configure the programmable hardware element  206 . For example, in the embodiment where the image acquisition device  134  is coupled to the computer system  102  over a network, deploying the graphical program may comprise the computer system  102  deploying the graphical program over the network to the image acquisition device  134 . The hardware configuration corresponds to a hardware implementation of the graphical program. In one embodiment, downloading the hardware configuration onto the programmable hardware element  206  may comprise the following steps: generating a hardware description based on the graphical program, where the hardware description describes a hardware implementation of the graphical program; converting the hardware description into a netlist; compiling the netlist format into a hardware program file; and downloading the hardware program file to the programmable hardware element to configure the programmable hardware element. These steps are discussed below.  
      After the downloading step is performed, the programmable hardware element is configured with a hardware implementation of the graphical program. At this point, in step  868  the image acquisition device (e.g., smart camera  190 ) may be optionally disconnected from the computer system  102 , and may possibly be deployed for operation. For example, in the case of smart camera  190 , the smart camera  190  may be disconnected from the computer system  102  and deployed in a vision application, such as a manufacturing vision inspection application, a manufacturing assembly application, or other vision application. If the image acquisition device is an image acquisition card or board that is designed to be located in a slot of the computer  102 , the image acquisition card or board  134  may optionally remain in the computer system  102  for use, or may be transferred to a different computer system. Alternatively, the method described above may be repetitively used to manufacture a plurality of image acquisition devices  134  (e.g., smart camera  190 ) for later sale. As another alternative, the method described above may be used to configure an image acquisition device  134  that has already been deployed, where the image acquisition device  134  is configured over a network, i.e., where the hardware configuration is downloaded onto the image acquisition device  134  (or other instrument) over a network.  
      After the programmable hardware element  206  in the image acquisition device  134  (e.g., smart camera  190 ) is configured with a hardware implementation of the graphical program, the image acquisition device  134  can be used in an application. Thus the image acquisition device  134  or smart camera  190  may acquire an image of an object in step  870 , e.g., from a camera  132 , or the camera in smart camera  190  may acquire the image. The programmable hardware element  206  in the image acquisition device  134  may then execute in step  872  to perform the image processing function on the image.  
      While the programmable hardware element  206  in the image acquisition device  134  executes to perform the image processing function on the image, if the graphical program includes a user interface portion, this user interface portion may optionally be presented on a display during this time in step  874 . The code corresponding to the user interface portion may be executed by a processor  160  in the computer system  102  or by a processor  212  on the image acquisition device  134 . The user interface portion may operate as a front panel for the image acquisition device  134 . The user may optionally provide user input to the user interface portion on the display to control the image acquisition device  134  while the programmable hardware element  206  in the image acquisition device  134  executes to perform the image processing function on the image. For example, the user interface portion may be compiled into executable code for execution by a processor ( 160  or  212 ) and stored in a memory ( 166  or  214 ) accessible by the processor. The processor may then execute the executable code (the user interface portion) from the memory to present the user interface portion on the display.  
      In an embodiment where the image acquisition device  134  (or smart camera  190 ) includes the processor  212  and the memory  214 , the processor  212  in the image acquisition device may execute the executable code from the memory  214  to present the user interface portion on the display during the image acquisition device  134  (or smart camera  190 ) executing to perform the image processing function on the image.  
      In another embodiment, the processor  160  of the computer system  102  may execute the executable code from the memory  166  to present the user interface portion on the display during the image acquisition device  134  (or smart camera  190 ) executing to perform the image processing function on the image.  
       FIG. 8B —Configuring an Image Acquisition Device or Smart Camera to Perform an Image Processing Function  
       FIG. 8B  is an exemplary embodiment illustrating a method for configuring an image acquisition device  134 , such as smart camera  190 , with a graphical program to perform an image processing function, where the image acquisition device  134  (or smart camera  190 ) includes a functional unit, more specifically, a processor  212  and memory  214 . The method shown in  FIG. 8B  is another, more detailed version of the method of  FIG. 7  described above, and is similar to the method described above with reference to  FIG. 8A , differing from that method only in steps  866  and  872 . Thus, in describing this embodiment of the method, where the steps are the same as described above, an abbreviated description is provided. As noted above, in various embodiments, various steps in the method may occur concurrently, or in a different order than shown. Additionally, some steps may be omitted, or additional steps performed which are not shown, as desired. As shown, this method may operate as follows.  
      First, in step  862  a graphical program may be created on the computer system  102  (or on a different computer system), as described above with reference to  FIG. 8A , step  862 .  
      In step  864  the image acquisition device  134  (e.g., smart camera  190 ) may be coupled to the computer system  102 , such as over a network, communication cable(s), through wireless means, or by any other method of coupling, as described above with reference to  FIG. 8A , step  864 .  
      In step  867  the graphical program may be downloaded to the memory  214  of the image acquisition device  134  (e.g., smart camera  190 ). As mentioned above, downloading the graphical program onto the memory  214  may comprise the following steps: generating an executable program (an executable program) based on the graphical program which implements the functionality of the graphical program; and transferring the executable program to the memory  214  on the image acquisition device. As also mentioned above, downloading the graphical program onto the memory  214  may comprise downloading the graphical program (or executable program) onto the memory  214  over a network.  
      After the downloading step is performed, the image acquisition device  134  is configured to perform the image processing function implemented by the graphical program. At this point, in step  868  the image acquisition device  134  (e.g., smart camera  190 ) may be optionally disconnected from the computer system  102 , and may possibly be deployed for operation, as described above in step  868  of  FIG. 8A .  
      After the image acquisition device  134  (e.g., smart camera  190 ) is configured with the graphical program, i.e., after the graphical program is loaded into the memory  214 , the image acquisition device  134  can be used in an application. Thus the image acquisition device  134  or smart camera  190  may acquire an image of an object in step  870 , e.g., from a camera  132 , or the camera in smart camera  190  may acquire the image. The image acquisition device  134  may then execute to perform the image processing function on the image, as indicated in step  873 .  
      While the image acquisition device executes to perform the image processing function on the image, if the graphical program includes a user interface portion, this user interface portion may optionally be presented on a display during this time in step  874 , as described above in step  874  of  FIG. 8A .  
      In one embodiment, the user may optionally provide user input to the user interface portion on the display to control the image acquisition device while the image acquisition device  134  (i.e., the processor  212  and memory  214 ) executes to perform the image processing function on the image.  
      In one embodiment, the image acquisition device executing to perform the image processing function on the image in  708  may comprise the processor  212  in the image acquisition device  134  executing the graphical program from the memory  214 . In the embodiment where the executable program is generated from the graphical program, the image acquisition device executing to perform the image processing function on the image may comprise the processor in the image acquisition device executing the executable program (in executable form) from the memory  214 .  
      In one embodiment, the processor  212  in the image acquisition device may execute the executable code from the memory  214  to present the user interface portion on the display during the image acquisition device  134  (or smart camera  190 ) executing to perform the image processing function on the image. In other words, the processor  212  may execute both portions of the graphical program concurrently, such as by threading or multi-tasking. In another embodiment, the image acquisition device  134  (or smart camera  190 ) may include multiple processors, e.g.,  212 A and  212 B, in which case the first portion of the graphical program (such as the user interface portion) may be executed by processor  212 A from memory  214  (or a first memory  214 A), while the second portion (such as the image processing portion) may be executed by processor  212 B from memory  214  (or a second memory  214 B), or from image memory  284 .  
      In one embodiment, the graphical program which implements the image processing function may already have been created, for example, by a third party. The method may then comprise coupling the image acquisition device  134  to a computer system  102  which stores the graphical program, where the image acquisition device comprises a functional unit; and deploying the graphical program onto the functional unit in the image acquisition device  134  to configure the functional unit; where after the deploying, the functional unit is operable to implement the graphical program. In other words, step  862 , and possibly steps  868  forward, may be omitted from the methods shown in  FIGS. 8A and 8B .  
       FIG. 9 —Block Diagram of Conversion of a Graphical Program Into Hardware and Software Descriptions  
       FIG. 9  is a block diagram illustrating the conversion of a graphical program, such as a graphical image processing or machine vision program, into hardware and software descriptions. The graphical program  300  may comprise graphical code, such as interconnected function nodes or icons. The graphical code in the graphical program may use graphical data flow, graphical control flow and/or graphical execution flow constructs, as noted above. On the display, the graphical program may be represented as interconnected icons or function nodes. In the memory of the computer system, the graphical program  300  may comprise data structures (or scripts or code) representing functional operations, data flow and/or control flow, and execution order. As the user assembles the graphical program on the display, e.g., by selecting, arranging, and connecting various icons or function nodes on the display, the data structures (or scripts or code) may be automatically created and stored in memory.  
      The graphical program  300  may be created with various development tools. For example, the graphical program may be created using the following development systems: LabVIEW, BridgeVIEW, DASYLab, Visual Designer, HP VEE (Visual Engineering Environment), Snap-Master, GFS DiaDem, ObjectBench, Simulink, WiT, Vision Program Manager, Hypersignal, VisiDAQ, Vis Sim, Truly Visual, and Khoros, among others. In the preferred embodiment, graphical program  300  is a LabVIEW graphical program or virtual instrument (VI).  
      In one embodiment, programs of the present invention may create a VDiagram tree  302  from the data structures of the graphical program  300 . The VDiagram tree  302  is an abstract hardware graph which represents at least a portion of the graphical program  300 . The graph may be organized in a way that facilitates the generation of specific types of descriptions by back end programs of the present invention. In one embodiment, the graphical programming system automatically creates and stores a VDiagram tree  302  (abstract hardware graph) in response to a user&#39;s creation of a graphical program. In this instance, conversion from graphical program data structures to a VDiagram tree is not necessary.  
      A hardware description  304  may be generated from the abstract hardware graph  302  by a back end program. The hardware description  304  may be in any of various hardware description languages such as VHDL, EDIF, and Verilog. In the preferred embodiment, the hardware description  304  comprises one or more VHDL files. A hardware netlist  306  may be generated from the hardware description using various synthesis tools. As noted above, the term “netlist” comprises various intermediate hardware-specific description formats comprising information regarding the particular hardware elements required to implement a hardware design and the relationship among those elements. In the preferred embodiment, the hardware netlist  306  is an FPGA-specific netlist. The hardware netlist  306  is used to create or configure one or more functional hardware devices or hardware elements  308  which are configured to execute the portion of the graphical program  300  that is represented by the abstract hardware graph  302 .  
      Hardware element  308  may comprise any of various devices. For example, hardware  308  may comprise a programmable logic device (PLD) such as an FPGA or CPLD. However, hardware  308  may comprise other types of hardware devices, such as a traditional circuit board which is created using the hardware netlist  306 . In the preferred embodiment, hardware  308  is an interface card comprising an FPGA, where the interface card is comprised in the computer system where the graphical program  300  is created. The hardware  308  may also be comprised in an external device connected to the computer system where the graphical program  300  is created. The hardware  308  may be connected to the computer over an external serial or parallel bus, or over a network, such as the Internet.  
      As shown in  FIG. 9 , software description source code  310  may also be generated from the abstract hardware graph  302  by a back end program. The source code  310  may be in various source code languages such as C, C++, Java, etc. Machine code  312  may be produced from the source code  310  using various source code compilers. Linked machine code  314  may be produced from the machine code  312  using various machine code linkers. The linked machine code  314  is executable to perform the operations of the portion of the graphical program  300  that is represented by the abstract hardware graph  302 .  
       FIG. 10 —Block Diagram of Generation of Hardware and Software Descriptions from a Vdiagram Tree  
       FIG. 10  is a block diagram illustrating the generation of various types of hardware and software descriptions from a VDiagram tree. As described for  FIG. 9 , programs of the present invention create a VDiagram tree  302  from a graphical program  300 . The VDiagram tree  302  represents at least a portion of the graphical program  300 . Back end programs  330  generate hardware descriptions from the VDiagram tree  302 . Exemplary back end programs  330 A,  330 B, and  330 C are illustrated. Back end  330 A generates a VHDL hardware description comprising one or more VHDL files. Back end  330 B generates an EDIF hardware description comprising one or more EDIF files. Back end  330 C generates a C source code software description comprising one or more C files. It is also contemplated that other back ends may be used to generate hardware descriptions in other hardware and/or software programming languages.  
      The number and type of back end programs that may be present are not limited. In the preferred embodiment, one or more back end programs may be called automatically as part of a process initiated by a user to generate hardware/software descriptions for the graphical program  300 . In another embodiment, the VDiagram tree  302  may be generated and saved to a file, and the user may call a back end program at a later time to generate a hardware/software description.  
      As described above for  FIG. 9 , appropriate synthesis tools or compilers may be called to convert a hardware/software description into another format such as an FPGA-specific netlist or compiled machine code.  
       FIG. 11 —Block Diagram of Conversion of a Graphical Program into a Hardware Description for an FPGA  
       FIG. 11  illustrates the exportation of at least a portion of a graphical program  300  into a hardware description and the use of the hardware description to program an FPGA. As described above for  FIG. 10 , the VDiagram tree  302  comprises information representing the graphical program  300 , including the functional operations of the program. As described in detail below, the VDiagram tree comprises VDiagrams, each of which maintains a list of components. This list of components includes components which represent functional operations.  
      A back end program converts the VDiagram tree  302  to a hardware description  304 . Back end programs may implement the functionality of the components in the VDiagram component lists using constructs of their respective description languages. For example, a VHDL back end may create VHDL code to implement a component that performs a particular mathematical algorithm such as an exponential calculation. However, in one embodiment, such functional components are simply referenced as library components.  
       FIG. 11  illustrates one embodiment in which the VDiagram tree references one or more library components. One embodiment of the present invention comprises pre-compiled function blocks  342  which implement these library components for particular hardware devices such as FPGAs. Various FPGA netlist synthesis tools may be called to generate an FPGA netlist  340  from the hardware description  304 . These synthesis tools may incorporate the pre-compiled function blocks  342  into the FPGA netlist  340 . Also, as shown, the synthesis tools may utilize hardware target-specific information in creating the netlist. For example, the exact form that the FPGA netlist takes may depend on the particular type of FPGA that will use the netlist, since FPGAs differ in their available resources.  
      An FPGA bit stream program file  346  may be generated from the FPGA netlist  340  using readily available synthesis tools. This FPGA program file may be uploaded to an FPGA  348 . The FPGA  348  may be comprised in a hardware device such as an interface board. After being programmed with the program file  346 , the FPGA is able to execute the portion of the graphical program  300  that is exported to the hardware description  304 . If the entire graphical program is not exported to the hardware description, then a portion of the program may execute on the general purpose CPU of the computer system. This portion preferably comprises the supervisory control and display portion of the program. Details follow on how the execution of the FPGA portion is coordinated with the execution of the main CPU portion and how the external hardware resource requirements for the FPGA portion are managed.  
       FIG. 12 —Block Diagram of Conversion of a Graphical Program into a Software Source Code Description with Compilation and Linkage  
       FIG. 12  illustrates the exportation of at least a portion of a graphical program  300  into a software source code description and the compilation and linkage of the source code. As shown, the graphical program data structures may be first converted to a VDiagram tree  302  and then to software description source code  310 .  
      As described above for  FIG. 10 , in the preferred embodiment the VDiagram tree  302  references library components to represent various functional components of the graphical program. These library components may be implemented in libraries, class libraries, macro definitions, etc.  360 . As shown in  FIG. 12 , these class libraries, etc. may be used to produce the machine code  312  from the source code  310 . Also, binary object libraries  362  may implement some functionality of the software description. These binary object libraries may be linked in with the machine code  312  is linked to produce the linked executable code  314 . Libraries  360  and  362  may also contain compiler-specific or platform-specific information necessary to produce executable code  314 . Linked code  314  may be executed to perform the operations of the portion of the graphical program that is exported to the software source code description  310 .  
       FIG. 13 —Conversion of a Graphical Program into a Hardware Implementation  
       FIG. 13  is a flowchart diagram illustrating operation of one embodiment of the present invention. One embodiment of the present invention comprises a computer-implemented method for generating hardware and/or software implementations of graphical programs or graphical code. It is noted that various of the steps in the flowchart can occur concurrently or in different orders.  
      One goal of the present invention is to provide a development environment that will seamlessly allow use of a graphical programming system to design applications for reconfigurable or programmable hardware. In the preferred embodiment where the graphical programming system is LabVIEW, the present invention allows LabVIEW users to design applications in LabVIEW for reconfigurable hardware.  
      Many applications, such as signal processing and real-time motion control, are easily implemented in a graphical programming language, such as the LabVIEW G language. However, in some instances traditional software compilation methods cannot produce an application that is fast enough to meet a user&#39;s needs. The present invention solves this problem by allowing a user to convert their graphical program, e.g., a G program, into application-specific hardware such as a programmed FPGA. The hardware maintains the exact functionality of the graphical program while running at speeds far exceeding that of traditional general-purpose processor platforms. One current implementation of the present invention is a desktop or embedded PC that contains an FPGA-based and/or processor based card or board.  
      In one embodiment, the system appears as a conventional graphical programming system while providing a seamless interface to the reconfigurable hardware. For example, the preferred embodiment of the invention, referred to as “FPGA LabVIEW”, provides a seamless interface to an FPGA. FPGA LabVIEW appears from the outside to be exactly the same as the normal LabVIEW graphical program development system.  
       FIG. 13  illustrates one embodiment of the translation process from a graphical program to a hardware description that corresponds to the graphical program. A graphical programming application that is being targeted for a hardware implementation is designed in the same way as an ordinary graphical programming application. As shown, in step  862  the user first creates a graphical program, also sometimes referred to as a block diagram. As described above, a design may be entered and debugged in the traditional software-based manner. In one embodiment, the graphical program comprises a graphical data flow diagram which specifies functionality of the program to be performed. This graphical data flow diagram is preferably directly compilable into machine language code for execution on a computer system.  
      When the design is finalized, the user can instruct the system to compile the design for the FPGA hardware. Unfortunately, some graphical programming constructs may not be efficiently implemented in FPGA hardware. For example, file I/O is a task that is usually better left to the general-purpose host processor. The present system in one embodiment is capable of bisecting a design into hardware portions and software portions.  
      Steps  404 - 414  are an example implementation of step  866  of  FIG. 8A .  
      In step  404 , the user may optionally select a first portion of the graphical program for conversion to a hardware implementation. This first portion of the graphical program which is desired for hardware implementation preferably comprises portions of the graphical program, e.g., particular subprograms, which require a fast or deterministic implementation and/or are desired to execute in a stand-alone hardware unit. In general, portions of the graphical program which are desired to have a faster or more deterministic execution are selected in step  404  and converted into the hardware implementation in steps  406 - 414 . A default case is that the entire block diagram portion of the graphical program is selected for hardware implementation.  
      In step  422  the remaining portions of the graphical program which were not selected in step  404 , if any, may be compiled into machine code for execution on a CPU, such as the host processor in the computer  102  or the processor  212  comprised on the interface card  134 . The first portion of the program selected in step  404  preferably excludes program portions involving supervisory control and display. This enables the supervisory control and display portions to execute on the host CPU, which is optimal for these elements of the program.  
      In one embodiment, during creation of the graphical program in step  862  the user may specify portions, e.g. subprograms, which are to be exported to the hardware description format for conversion into a hardware implementation. In another embodiment the user selects which modules or subprograms to export to the hardware implementation at the time when the conversion process is initiated. In another embodiment, the entire graphical program may be selected for conversion to a hardware implementation, and thus step  422  may not be performed.  
      In step  406  the graphical program portion selected in step  404  may first be processed to create an abstract hardware graph called a VDiagram tree, described above, which serves as an intermediate data structure. The VDiagram tree may contain a complete hardware representation of the program, but is not specific to any hardware description language. For example, the VDiagram tree may comprise data structures representing hardware signals that implement the data flow within the graphical program, as well as data structures representing hardware signals that are added to preserve the proper execution flow (enable signals).  
      In step  408 , a back end program may be called to parse the VDiagram tree and generate a hardware description from it. The back end may translate the information contained in the VDiagram tree into a specific hardware description language. For example, a VHDL back end may be called to generate a VHDL file or set of files describing the program. The hardware description comprises a high-level hardware description of function blocks, logic, inputs, and outputs which perform the operation indicated by the portion of the graphical program selected in step  404 .  
      Various types of back end programs may be present. Back end programs may generate software source code descriptions as well as hardware description language descriptions. For example,  FIG. 10  illustrates a back end  330 A which uses the VDiagram tree to generate one or more VHDL files; back end  330 B which generates one or more EDIF files; and back end  330 C which generates one or more C files. These three back ends are representative only. Other back ends may generate other types of descriptions for the program. For example, a Verilog back end may generate a Verilog file for the program. Also, more than one back end may be called to generate different program descriptions. In the preferred embodiment, a VHDL back end generates a VHDL description which may then be compiled and used to program a programmable logic device such as an FPGA.  
      In step  410  the method may operate to convert the hardware description into an FPGA-specific netlist. The netlist describes the components required to be present in the hardware as well as their interconnections. Conversion of the hardware description into the FPGA-specific netlist is preferably performed by any of various types of commercially available synthesis tools, such as those available from Xilinx, Altera, etc.  
      In one embodiment, the converting step  410  may utilize one or more pre-compiled function blocks from a library of pre-compiled function blocks  342 . Thus, for certain function blocks which are difficult to compile, or less efficient to compile, from a hardware description into a netlist format, the hardware description created in step  408  includes a reference to a pre-compiled function block from the library  342 . Alternatively, hardware implementations for all of the function blocks are included in the function library. The respective pre-compiled function blocks are simply inserted into the netlist in place of these references in step  410 . The preferred embodiment of the invention thus includes the library  342  of pre-compiled function blocks, also referred to as the component library, which are used in creating the netlist. The preferred embodiment also includes hardware target specific information  344  which is used by step  410  in converting the hardware description into a netlist which is specific to a certain type or class of FPGA.  
      In step  412  the method may operate to compile the netlist into an FPGA program file, also referred to as a software bit stream. The FPGA program file is a file that can be readily uploaded to program an FPGA.  
      After the netlist has been compiled into an FPGA program file in step  412 , then in step  414  the method may operate to transfer the FPGA program file to the FPGA, to produce a programmed hardware equivalent to the graphical program. Thus, upon completion of step  414 , the portion of a graphical program referenced in step  404  is comprised as a hardware implementation in an FPGA or other programmable hardware element.  
      In the preferred embodiment, the hardware description is passed transparently through the FPGA vendor&#39;s synthesis tools. Because the vendor&#39;s tools may take a considerable amount of time to process the design and generate a programming bitstream, it is recommended that this only be done after the design has been debugged using traditional software-compilation techniques.  
      As described above, the present invention may run on PC computers equipped with an FPGA-based expansion card on the PCI bus. Embodiments of the FPGA-based expansion card were described with reference to  FIGS. 5A-5C  (and possibly  6 A- 6 D). The graphical programming system may upload the programming bitstream generated by the FPGA vendor&#39;s design tools into the FPGA on this board. The FPGA then may begin processing data, and the graphical programming system may coordinate data flow between the FPGA and the host CPU.  
      It is noted that various of the above steps can be combined and/or can be made to appear invisible to the user. For example, steps  410  and  412  can be combined into a single step, as can steps  404 - 410 . In the preferred embodiment, after the user creates the graphical program in step  402 , the user simply selects a hardware export option and indicates the hardware target or destination, causing steps  404 - 414  to be automatically performed.  
       FIG. 13  applies to the preferred embodiment in which the programmable hardware element is an FPGA. However, the same or similar steps may be applied to convert a graphical program into a hardware implementation for other types of programmable or (re)configurable hardware, such as a CPLD.  
       FIG. 14 —Creation of a Graphical Program  
       FIG. 14  is a more detailed flowchart diagram of step  862  of  FIGS. 8A and 13 , illustrating creation of a graphical program according to one embodiment of the invention. As shown, in step  430  the user may arrange on a screen (i.e., a display device) a graphical program or block diagram. This may include the user placing and connecting, e.g., wiring, various icons or nodes on the display screen in order to configure a graphical program. More specifically, the user may select various function icons or other icons and place or drop the icons in a block diagram panel, and then connect or “wire up” the icons to assemble the graphical program. The user may also assemble a user interface, which may be referred to as a front panel, comprising controls and indicators which indicate or represent input/output to/from the graphical program. A graphical program targeted to measurement or automation applications may be referred to as a virtual instrument (VI). The graphical program or VI may have a hierarchy of sub-graphical programs or sub-VIs.  
      In the preferred embodiment, the graphical programming system is the LabVIEW graphical programming system available from National Instruments. For more information on creating a graphical program in the LabVIEW graphical programming system, please refer to the LabVIEW system available from National Instruments as well as the above patent applications incorporated by reference.  
      In response to the user arranging on the screen a graphical program, the method may operate in step  432  to develop and store a tree of data structures which represent the graphical program. Thus, as the user places and arranges on the screen function nodes, structure nodes, input/output terminals, and connections or wires, etc., the graphical programming system may operate to develop and store a tree of data structures which represent the graphical program. More specifically, as the user assembles each individual node and wire, the graphical programming system may operate to develop and store (or populate) a corresponding data structure in the tree of data structures which represents the individual portion of the graphical program that was assembled. Thus, steps  430  and  432  may be an iterative process which is repetitively performed as the user creates the graphical program. In one embodiment, the graphical programming system may automatically develop and store VDiagram data structures in response to the user creating the graphical program.  
      In an alternate embodiment, as the user places, arranges and interconnects nodes on the display, scripts, DLLs, or other code may be created in memory.  
      In one embodiment, the user may optionally place constructs in the graphical program which indicate respective portions of graphical code which are either to be compiled into machine code for execution by a CPU or converted to a hardware description for implementation in a programmable hardware device such as an FPGA.  
      Thus, the various methods described above may operate to deploy a graphical program implementing a function, such as an image processing or machine vision function, onto a programmable or configurable device, such as an image acquisition device, e.g., an image acquisition board or smart camera, thereby enabling the device to perform the function.  
      Although the system and method of the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.