 |
Description  |
|
|
RESERVATION OF COPYRIGHT
A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure
as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to graphical systems for creating and executing data flow programs, and more specifically to method and apparatus for improved local and global variable capabilities in a graphical data flow programming environment
2. Description of the Related Art
A computer system can be envisioned as having a number of levels of complexity. Referring now to FIG. 1, the lowest level of a computer system may be referred to as the digital logic level. The digital logic level comprises the computer's true
hardware, primarily consisting of gates which are integrated together to form various integrated circuits. Other hardware devices include printed circuit boards, the power supply, memory, and the various input/output devices, among others. Gates are
digital elements having one or more digital inputs, signals representing 0 or 1 states, and which compute an output based on these inputs according to a simple function. Common examples of gates are AND gates, OR gates, etc. It is also noted that there
is yet another level below level 0 which can be referred to as the device level. This level deals with the individual transistors and semiconductor physics necessary to construct the gates comprising the digital logic level.
The next level, referred to as level 1, is referred to as the microprogramming level. The microprogramming level is essentially a hybrid between computer hardware and software. The microprogramming level is typically implemented by software
instructions stored in ROM (read only memory), these instructions being referred to as microcode. The microprogramming level can be thought of as including various interpreters comprised of sequences of microcode which carry out instructions available
at the machine language level, which is at level 2. For example, when an instruction such as an arithmetic or shift function appears at the machine language level, this instruction is carried out one step at a time by an interpreter at the
microprogramming level. Because the architecture of the microprogramming level is defined by hardware, it is a very difficult level in which to program. Timing considerations are frequently very important in programming at this level and thus usually
only very skilled, experienced microprogrammers operate at this level.
As mentioned above, the level above the microprogramming level is referred to as the machine language level. The machine language level comprises the 1's and 0's that a program uses to execute instructions and manipulate data. The next level
above the machine language level is referred to as the assembly language level. This level includes the instruction set of the computer system, i.e. the various op codes, instruction formats, etc. that cause the computer to execute instructions. In
assembly language each instruction produces exactly one machine language instruction. Thus, there is a one to one correspondence between assembly language instructions and machine language instructions. The primary difference is that assembly language
uses very symbolic human-readable names and addresses instead of binary ones to allow easier programming. For example, where a machine language instruction might include the sequence "101101," the assembly language equivalent might be "ADD." Therefore,
assembly language is typically the lowest level language used by programmers, and assembly language programming requires a skilled and experienced programmer.
The next level includes high level text-based programming languages which are typically 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. The high level programming languages in this level, as well as the assembly language level, are referred to in this
disclosure 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'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. For example, text-based programming environments have traditionally used a number of programs to
accomplish a given task. Each program in turn often comprises one or more subroutines. Software systems typically coordinate activity between multiple programs, and each program typically coordinates activity between multiple subroutines. However, in
a text-based environment, techniques for coordinating multiple programs generally differ from techniques for coordinating multiple subroutines. Furthermore, since programs ordinarily can stand alone while subroutines usually cannot in a text-based
environment, techniques for linking programs to a software system generally differ from techniques for linking subroutines to a program. Complexities such as these often make it difficult for a user who is not a specialist in computer programming to
efficiently program a computer system in a text-based environment.
The task of programming a computer system to model 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. For example, a computer programmer typically develops a conceptual model for a physical system which can be partitioned
into functional blocks, each of which corresponds to actual systems or subsystems. Computer systems, however, ordinarily do not actually compute in accordance with such conceptualized functional blocks. Instead, they often utilize calls to various
subroutines and the retrieval of data from different memory storage locations to implement a procedure which could be conceptualized by a user in terms of a functional block. In other words, the requirement that a user program in a text-based
programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master 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.
One particular field in which computer systems are employed to model physical systems is the field of instrumentation. An instrument is a device which collects information from an environment and displays this information to a user. Examples of
various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation,
humidity or temperature, among others. An instrumentation system ordinarily controls its constituent instruments from which it acquires data which it analyzes, stores and presents to a user of the system. Computer control of instrumentation has become
increasingly desirable in view of the increasing complexity and variety of instruments available for use.
In the past, many instrumentation systems comprised individual instruments physically interconnected. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user
generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone. An incremental improvement
in the manner in which a user interfaced with various instruments was made with the introduction of centralized control panels. In these improved systems, individual instruments were wired to a control panel, and the individual knobs, indicators or
switches of each front panel were either preset or were selected to be presented on a common front panel.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems the user interacted with a software program executing on the
computer system through the video monitor rather than through a manually operated front panel. These earlier improved instrumentation systems provided significant performance efficiencies over earlier systems for linking and controlling test
instruments.
However, these improved instrumentation systems had significant drawbacks. For example, due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it was often necessary for a user
to develop a program to control the new instrumentation system desired. As discussed above, computer programs used to control such improved instrumentation systems had to be written in conventional text-based programming languages such as, for example,
assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of instrumentation systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently
intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation data. Thus, development and
maintenance of the software elements in these instrumentation systems often proved to be difficult.
U.S. Pat. No. 4,901,221 to Kodosky et al discloses 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 the highest and most intuitive way in which to interact with a computer. Referring now to FIG. 1A, a graphically based programming environment can be represented at level 5 above text-based high
level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor such that the diagram created graphically displays a procedure or method for accomplishing a
certain result, such as manipulating one or more input variables to produce one or more output variables. As the user constructs the data flow diagram using the block diagram editor, machine language instructions are automatically constructed which
characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a text-based computer program solely by using a graphically based programming environment. This graphically based programming environment may
be used for creating virtual instrumentation systems and modeling processes as well as for any type of general programming.
In the method described in Kodosky et al, no methodology was provided to allow a user to implement a local variable that can only be accessed by a particular diagram or VI and which cannot be affected by VIs not in that diagram. However, it
would be highly desirable to have a local variable capability in a graphical programming environment for several reasons. First of all, as is well known to programmers in traditional text-based programming environments, local variables enable a user to
ensure that the variable used in a particular subroutine or module will not be affected by the same variable used in other subroutines in other modules. This provides a safer and cleaner programming interface. For example, in a large program where only
global variables are allowed, the user may not be able to keep track of the order in which that global variable is updated, and different modules may affect the global variable in undesirable ways. However, with a local variable which is local to a
particular subroutine, the user can guarantee that only that subroutine will use that local variable and hence the variable will not be affected by calls or operations in other subroutines.
In addition, the system and method described in Kodosky et al included only one icon on a block diagram where a user could change or read a value in a control. In other words, no two controls could occupy the same storage location, i.e., a user
could not create a control representing a storage location and then place subsequent copies of that icon in other places in the block diagram. Since multiple locations could not be created, there was no problem with these locations being updated in an
undetermined order. However, this limited program flexibility and was hence undesirable because a user could only update the input to a control at one place in a block diagram, i.e., the input to a control could not be updated in multiple places
concurrently in a block diagram. For example, if a program had two loops running and it was desired to stop them with only one button, in the method described in Kodosky et al this could only be accomplished using a global variable hooked to the button
with both loops reading from the global. The use of a global variable in this situation is undesirable due to the problems mentioned above.
Also, controls and indicators which could be created by a user in Kodosky et al. could be either read from or written to by a user, but not both. Input terminals associated with controls were read only and output terminals associated with
indicators were write only. Thus, a control was either read only or write only, but not both. One advantage of using read only input terminals and write only output terminals was that race conditions could not occur, i.e. race conditions cannot occur
in a data flow program between a read only control and a write only indicator. However, providing only read only or only write only controls greatly limits the flexibility of the program. It would be highly desirable to allow a user to read from or
write to any control or indicator at any point in a diagram at any time.
Therefore, a method and apparatus is desired which provides a local variable capability for controls and indicators to allow a user to read and write the memory associated with controls and indicators in multiple places in a block diagram.
In the system and method described in Kodosky et al., an iterative loop function and an indefinite loop function were included to allow a user to perform iterations on data. These loop functions included shift registers which provided these
loops with the capability of storing data from one iteration to the next in order for them to operate on previous data or to enable them to remember what had occurred in a previous iteration. Shift registers for storage of values could be initialized
upon entering a loop, i.e., assigned values upon entering the loop, and then could be updated subsequently during execution of the loop. The loop could change these variables a multitude of times depending on the desired result. Also, the shift
registers could be left uninitialized, i.e., not assigned values when the loop was entered. The use of shift registers in loops can be best illustrated by the Fibonacci number problem which is described in U.S. Pat. No. 4,901,221. In the case where
the shift registers are not initialized, the values in the shift registers on entering the loop are the same as the values written to the shift registers the previous time the loop was executed. In this manner, a shift register that is not initialized
on entry in a loop could essentially be used as a global variable because it "remembers" what happened on previous updates.
Therefore, by creating a subVI having a loop wherein the shift register is not initialized upon entering the loop, the shift register essentially behaved as storage for a global variable. By placing this subVI wherever desired, the user
essentially could place global variables wherever desired in a VI. This was very common practice in order to use global variables. However, one problem with this method of creating a global variable was the associated storage and execution overhead.
This was because a loop structure contained within a subVI had to be created in order to merely update a global variable. The creation of a loop structure and its associated subVI require some amount of code. Also, if a global variable was required to
be updated, a function call to a subVI which in turn executed a loop was performed merely to update the global variable. This resulted in a certain amount of execution overhead, i.e., a much greater amount of work than should be necessary to simply
update a global variable.
Therefore, a system and method is desired which allows a new form of global variable to be used in a graphical data flow environment with a reduced amount of execution and storage overhead.
SUMMARY OF THE INVENTION
The present invention comprises local and global variable capabilities which enable a user to more effectively create block diagram programs and model processes in a graphical data flow programming environment. The local and global variables
include associated panel controls which allow a user to read or adjust the values of these variables during program execution.
A global variable is created by placing a global variable icon in a block diagram and creating an associated global variable panel. The global variable panel is not associated with a VI. Therefore, a global variable is not created in a
functional VI, but rather is created with its own panel not associated with a VI whose only purpose is to facilitate the implementation of a global variable. The user then defines the data type of the global variable and assigns a name to the global
variable. Therefore, global variables are not required to be implemented as shift registers in a loop contained within a sub-V This greatly reduces the storage and execution overhead associated with creating and using global variables. Since a global
variable is associated with a panel, the user can view the global variable updating on the panel during execution of a VI. This greatly facilitates debugging. The user can also change the value of the global variable during execution.
A local variable is created in a similar manner to a global variable. However, unlike a global variable a local variable is created in a functional VI. In other words, the data storage of a local variable is provided by one of the controls on a
VI's front panel. Writing to a local variable has the same result as passing data to the control terminal, except that the user can write to it even though it is a control. Also, the user can have any number of local variable references to a given
front panel control with some in write mode and others in read mode. One distinction between local and global variables is that a local variable is peculiar to the panel corresponding to the VI where the local is created, whereas a global variable is
global to all VIs.
A local variable reference allows the user to use a front panel control as both an input and an output. One benefit of this local variable capability is that local variables can be used in their respective VIs and are guaranteed not to be
affected by other VIs or other block diagrams. This provides a cleaner programming environment and ensures that a user's local variable will not be affected by undesirable changes in other VIs. A second benefit of the local variable capability of the
present invention is that a user can have multiple functions operating concurrently wherein each function can potentially affect the input or output to a control or indicator. Finally, the present invention allows a user to implement a read/write
control to more effectively interact with the front panel.
BRIEF DESCRIPTION OF TIlE DRAWINGS
The purpose and advantages of the present invention will be apparent to those skilled in the art from the following detailed description in conjunction with the appended drawings in which:
FIG. 1 illustrates various levels of complexity in a computer system according to the prior art;
FIG. 1A illustrates the various levels of complexity of a computer system including a graphical programming environment as the highest level;
FIG. 2 is a block diagram illustrating a system for modeling a process according to the present invention;
FIG. 3 Is an illustrative drawing of a representation of a virtual instrument produced using the system of FIG. 2;
FIG. 4 shows a block diagram of an instrumentation system including the system of FIG. 2;
FIG. 5 is a representative drawing of various choices for an illustrative hardware instrumentation system of the preferred embodiment;
FIG. 5A is an illustrative hardware instrumentation system of the preferred embodiment;
FIG. 6 is a block diagram of the computer system of FIGS. 5 and 5A;
FIG. 7 shows a block diagram representing an exemplary data flow system;
FIG. 8A illustrates a virtual instrument data structure diagram used by the system of FIG. 2 and the instrumentation system of FIG. 4;
FIG. 8B shows a legend applicable to the illustration of FIG. 8A;
FIGS. 9A-L are flowchart diagrams illustrating operation of the execution subsystem of FIGS. 2 and 4;
FIG. 10 shows an illustrative front panel produced using the front panel editor of the instrumentation system of FIG. 4;
FIG. 11 shows an illustrative icon produced using the icon editor of the instrumentation system of FIG. 4;
FIG. 12A shows a graphical representation of a sequence structure;
FIG. 12B shows a graphical representation of an iterative loop structure;
FIG. 12C shows a graphical representation of a conditional structure;
FIG. 12D shows a graphical representation of an indefinite loop structure;
FIG. 12E shows a graphical representation of shift registers on the indefinite loop structure of FIG. 12D;
FIG. 13 shows an illustrative block diagram generally corresponding to the graphical representation of a sequence structure shown in FIG. 12A;
FIG. 14 shows an illustrative block diagram generally corresponding to the graphical represention of an iterative loop structure shown in FIG. 12B;
FIG. 15 shows an illustrative block diagram generally corresponding to the graphical representation of a conditional structure shown in FIG. 12C;
FIG. 16 shows an illustrative block diagram generally corresponding to the graphical represention of an indefinite loop structure shown in FIG. 12D;
FIG. 17 shows an illustrative block diagram generally corresponding to the graphical representation of an iterative loop structure including a shift register shown on the left in FIG. 12E;
FIG. 18 illustrates a type descriptor used to describe data structures;
FIGS. 19A-K illustrate computer video displays during each successive step in a construction of an exemplary block diagram using the block diagram editor of FIGS. 2 or 4;
FIGS. 20A-C illustrate a system representation corresponding to FIGS. 19A-D;
FIGS. 21A-B illustrate a system representation corresponding to FIGS. 19E and 19H;
FIG. 22 is a drawing representing a block diagram according to the present invention as displayed on a computer video monitor to model the illustrative hardware system of FIG. 5A;
FIG. 23 illustrates serial execution mode of a VI;
FIG. 24 illustrates "wait" icon execution:
FIG. 25 illustrates parallel execution mode for a VI;
FIG. 26 illustrates a ready node list, also referred to as the run queue;
FIG. 27 illustrates how nodes are placed on the run queue as they become ready and are interleaved with other nodes;
FIG. 28 illustrates parallel execution of nodes in a block diagram virtual instrument;
FIGS. 29-37 illustrate various virtual instrument execution states;
FIG. 38 illustrates an execution road map;
FIG. 39 illustrates execution state symbols;
FIGS. 40-41 illustrates virtual instruments in various execution states;
FIG. 42 illustrates an example of the front panel for a temperature VI;
FIG. 43 illustrates the block diagram for the temperature VI in FIG. 42;
FIG. 44 illustrates the icon and connector for the temperature VI in FIGS. 42 and 43;
FIGS. 45 and 46 illustrate the front panel and block diagram of a VI that uses the temperature VI in FIGS. 42-44 as a subVI in its block diagram;
FIG. 47 illustrates a front panel and its associated block diagram;
FIG. 48 illustrates the run mode palette that appears at the top of the window when a VI is in run mode;
FIGS. 49A-D illustrate the run button and its associated icons;
FIGS. 50A-B illustrate the mode button in run mode and edit mode;
FIGS. 51A-B illustrate the icons associated with the continuous run button;
FIGS. 52A-B iilustrate breakpoint button icons;
FIGS. 53A-C illustrate icons associated with the step mode button;
FIGS. 54A-B illustrate execution highlighting button icons;
FIGS. 55A-B illustrate print mode button icons;
FIGS. 56A-C illustrate data logging button icons;
FIG. 57 illustrates the edit mode palette;
FIGS. 58A-B illustrate operating tool icons;
FIGS. 59A-C illustrate positioning tool icons;
FIGS. 60A-C illustrate labeling tool icons;
FIG. 61 illustrates the wiring tool;
FIGS. 62A-B illustrate the coloring tool;
FIG. 63 illustrates the menu bar in its active state;
FIG. 64 illustrates the file menu;
FIG. 65 illustrates the edit menu;
FIG. 66 illustrates the operate menu;
FIG. 67 illustrates the controls menu;
FIG. 68 illustrates the windows menu;
FIG. 69 illustrates the text menu;
FIG. 70 illustrates the menu bar when the diagram window is active;
FIG. 71 illustrates the functions menu;
FIG. 72 illustrates examples of numeric controls and indicators;
FIG. 73 illustrates examples of Boolean controls and indicators;
FIG. 74 illustrates how controls and indicators are configured;
FIG. 75 illustrates the panel window and diagram window of a VI illustrating nodes, terminals, and wires;
FIG. 76 illustrates examples of wire types;
FIGS. 77 and 78 are examples of VIs;
FIG. 79 illustrates icons grouped together into a lower level VI;
FIG. 80 illustrates a VI that adds three numbers together and returns their result;
FIG. 81 illustrates activating the icon editor;
FIG. 82 illustrates the tools that may be used to-create an icon design;
FIG. 83 illustrates the show connector function in the icon pane pop-up menu which may be used to define a connector;
FIG. 84 illustrates a front panel with the connector replacing the icon pane in the upper right corner of the panel window;
FIG. 85 illustrates the various choices for terminal patterns selected using the patterns option from the pop-up menu;
FIG. 86-88 illustrates how a user assigns front panel controls and indicators to the terminals using the wiring tool;
FIG. 89 illustrates the VI option which is used to place a VI as a subVI in the block diagram of another VI;
FIG. 90 illustrates the help window for a subVI icon;
FIG. 91 illustrates a While Loop selected from the Structs and Constants palette of the Functions Menu;
FIG. 92 illustrates a while loop;
FIG. 93 illustrates an example of a while loop;
FIG. 94 illustrates a for loop;
FIG. 95 illustrates an example of a for loop;
FIG. 96 illustrates the grey dot created during numeric conversions;
FIG. 97 illustrates a shift register;
FIG. 98 illustrates the operation of a shift register;
FIG. 99 illustrates a shift register with additional terminals to access values from previous iterations;
FIG. 100 illustrates operation of initialized and uninitialized shift registers;
FIG. 101 illustrates selection of a case structure from the Structs and Constats palette of the Function Menu.
FIG. 102 illustrates a numerical case structure;
FIG. 103 illustrates a Boolean case structure;
FIG. 104 is an example of a Boolean case structure;
FIG. 105 illustrates a sequence structure selected from the Structs and Constants menu palette of the Functions Menu;
FIG. 106 illustrates a sequence structure;
FIG. 107 illustrates an example of a three framed sequence structure using sequence locals;
FIG. 108 illustrates a formula node selected from the structs and constants palette of the functions menu;
FIG. 109 illustrates an equation implemented using arithmetic functions;
FIG. 110 illustrates the same equation implemented using a formula node;
FIG. 111 itlhstrates a waveform chart;
FIG. 112 illustrates the three update modes of a waveform chart, referred to as strip chart, scope chart, and sweep chart;
FIG. 113 illustrates how a scalar output is directly wired to a waveform chart;
FIG. 114 illustrates how a waveform chart accommodates more than one plot using the bundle function;
FIG. 115 illustrates selection of the local variable option from the Structs and Constants menu;
FIG. 116 illustrates the Structs and Constants menu;
FIG. 117 illustrates a local variable node;
FIG. 118 illustrates selection of an appropriate local variable by either choosing the variable from the Select Item menu or clicking on it using the operating tool;
FIG. 119 illustrates the change to read local option;
FIG. 120 illustrates local variables as well as the Select Item menu for these variables;
FIG. 121 illustrates multiple local variables accessing the same control;
FIG. 122 is a flowchart diagram illustrating operation of the block diagram editor when a local variable is created;
FIG. 123 illustrates the possible storage options for local variables of various data types;
FIG. 124 illustrates a front panel where one switch is used to control two charts having corresponding while loops;
FIGS. 125-126 are incorrect methods for implementing the front panel of FIG.
FIG. 127 is a method for implementing the front panel of FIG. 124 using local variables according to the preferred embodiment of the invention;
FIG. 128 illustrates a VI which uses local variables to update a string to display the loop currently executing;
FIG. 129 illustrates a VI that uses a local variable to update a string indicator and graph in multiple places on the diagram;
FIGS. 130-132 illustrate the frames of a sequence structure comprising a block diagram corresponding to the front panel of FIG. 129;
FIGS. 133-136 illustrate front panel and block diagram of a VI which uses a local variable to both read and write to a front panel control;
FIGS. 137 and 138 illustrate the front panel and block diagram of a VI that generates two diffe, r, ent random numbers and displays them on two waveform charts;
FIGS. 139 and 140 illustrate the front panel and block diagram of a VI that continuously generates random numbers and displays them inside digital indicators until a stop button is pressed;
FIG. 141 illustrates a modified block diagram of the VI illustrated in FIGS. 139-140, where the slide is immediately latched back to standby after each number is generated;
FIG. 142 illustrates selection of a global variable from the Structs and Constants menu;
FIG. 143 illustrates the Structs and Constants menu;
FIG. 144 illustrates a global variable node;
FIG. 145 illustrates a panel having three globals;
FIG. 146 illustrates selection of a specific global variable desired to be accessed;
FIG. 147 illustrates using the operating tool to click on a global variable node and choosing the desired global variable;
FIG. 148 illustrates a change to write global selection;
FIG. 149 is a flowchart diagram illustrating operation of the block diagram editor when a global variable is created;
FIG. 150 illustrates two VIs running simultaneously which include a global variable used to terminate both VIs;
FIGS. 151 and 154 illustrate the front panel and block diagram of a global variable VI;
FIGS. 152A-B illustrate elements used in the block diagram of FIG. 154;
FIG. 153 illustrates selection of a stop button used to pass values between two concurrently running VIs;
FIGS. 155-156 are a front panel and block diagram of a VI that reads from a global variable;
FIGS. 157-158 illustrate the front panel and block diagram of a VI that uses both global and local variables.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
The following U.S. Patents are hereby incorporated by reference.
U.S. Pat. No. 4,901,221 titled "Graphical System for Modeling a Process and Associated Method," issued on Feb. 13, 1990.
U.S. Pat. No. 4,914,568 titled "Graphical System for Modeling a Process and Associated Method," issued on Apr. 3, 1990.
The following U.S. patent applications are hereby incorporated by reference.
U.S. patent application Ser. No. 07/380,329 filed Jul. 12, 1989 titled "Graphical Method for Programming a Virtual Instrument," now U.S. Pat. No. 5,301,336.
U.S. patent application Ser. No. 07/979,416 filed Nov. 19, 1992 titled "Graphical System for Executing a Process and for Programming a Computer to Execute a Process, Including Graphical Variable Inputs and Variable Outputs" which is now U.S.
Pat. No. 5,291,587.
U.S. patent application Ser. No. 07/647,785 titled "Polymorphic Data Flow Block Diagram System and Method for Programming a Computer" and filed Jan. 30, 1991, which is now U.S. Pat. No. 5,301,301.
Referring now to FIG. 2, a system 28 for modeling a process or creating a data flow program is shown. The system 28 includes a respective block diagram editor 30, an execution subsystem 32, an icon editor 34, and a front panel editor 36 all
interconnected. The system 28 also includes a control processor 38 which connects to each of the front panel editor 36, icon editor 34, block diagram editor 30 and execution subsystem 32. The system 28 can be used for a number of purposes. In the
preferred embodiment, the system 28 is shown primarily in creating "virtual instruments" (VIs), which are instruments created in software. However, the system 28 of the present invention has many other applications, including modeling a process or any
other type of general programming.
As will be explained more fully below, the block diagram editor 30 is used to construct and display a graphical diagram, referred to as a block diagram, which visually displays a procedure by which a value for a input variable produces a value
for one or more output variables. This procedure, together with the input and output variables, comprises a process model. Furthermore, as the user constructs the graphical diagram, the block diagram editor 30 constructs execution instructions which
characterize an execution procedure which corresponds to the displayed procedure. In the preferred embodiment, the block diagram editor 30 constructs instructions in the machine language which execute the block diagram created by the user. The
execution subsystem 32 assigns at least one value to the input variable and executes the execution instructions to produce a value for the output variable. In the preferred embodiment, the block diagram editor 30 and the execution subsystem 32 are
constructed in software. The control processor 38 implements the block diagram editor 30 and the execution subsystem 32 of the preferred embodiment.
The system 28 permits a user to construct a virtual instrument (also referred to as a VI) 40 such as that represented in generalized form in the illustrative drawings of FIG. 3. The virtual instrument 40 includes a front panel 42 which permits
interactive use of the virtual instrument 40 by a user. As will be explained more fully below, the front panel 42 permits graphical representation of input and output variables provided to the virtual instrument 40. The respective graphical
representations on the front panel 42 for input and output variables are referred to as controls and indicators, respectively; although in some instances controls and indicators are referred to collectively as controls. The virtual instrument 40 also
includes an icon 44 which permits use of the virtual instrument 40 as a subunit in other virtual instruments (not shown). The virtual instrument 40 also includes a block diagram 46 which graphically provides a visual representation of a procedure or
method by which a specified value for an input variable displayed in the front panel 42 can produce a corresponding value for an output variable in the front panel 42. In other words, the user uses the block diagram editor 30 to create a graphical
program, and the resultant graphical icons appear in the block diagram 46. The virtual instrument 40 itself is a hierarchical construction which may comprise within its block diagram 46 respective icons 48 and 50 referencing other virtual instruments
(sub-VIs) indicated generally by respective blocks 52 and 54. The block diagram 46 may also include one or more "primitives" corresponding to simple functions that may be performed. Together sub-VIs, primitives and other types of data processing
elements comprised within the block diagram 46 are referred to as function icons. Function icons in the block diagram 46 have associated control means or software which implement the desired functions.
The generalized block diagram of FIG. 4 shows an instrumentation system 56 incorporating the system 28 shown in FIG. 2. Elements of the instrumentation system 56 which are substantially identical to those of second system 28 are designated with
the same reference numerals as those of the system 28 for convenience. The instrumentation system 56 includes a keyboard and display 58 and an instrument 60. In a presently preferred embodiment, the control processor 38 and the keyboard and display 58
may be implemented using any type of general purpose computer.
The instrumentation system 56 is preferably used to control the instrument 60, i.e., acquire data from the instrument 60, analyze that data, store that data, and present that data to the user in a meaningful way. The block diagram editor 30 can
also be used to create virtual instruments as desired.
FIG. 5 illustrates various design choices available in an instrumentation system 204 in the preferred embodiment. As shown, a computer system 206 programmed according to the present invention can interface with a unit under test 212, i.e., can
perform data acquisition and control of the unit under test 212, using a number of methods. These methods include using GPIB instruments 12, plug-in data acquisition boards 19 with associated signal conditioning logic 11, or VXI instruments 14. In
addition a serial RS-232 method (not shown) can be used, as desired. It is noted that the computer 206 may be any type of computer including any type of Apple computer, IBM PC-compatible computer, PS/2, Sun workstation, etc.
F | | |
