Title:

Automatic graph display

Document Type and Number:

United States Patent 7366993

Abstract:

System and method for displaying signals. First user input requesting display of a first signal is received, e.g., to a graphical user interface (GUI) comprised in a signal analysis function development environment, and the first signal programmatically analyzed in response to the first user input. A display tool operable to display the first signal is programmatically determined based on said analyzing, and the first signal displayed in the display tool, e.g., a data type of the first signal is determined, e.g., integer, floating point, Boolean, or user-defined data in a time-domain, frequency-domain, or spatial-domain, and the display tool programmatically determined based on the determined data type, e.g., via a loop-up table, where the display tool comprises an indicator operable to display the signal data. The signal comprises signal data, e.g., signal plot data, where the display tool comprises a graph, or tabular data, where the display tool comprises a table.

Inventors:

Joffrain, Philippe G. (Pflugerville, TX, US)
Cifra, Christopher G. (Austin, TX, US)
Moriat, Alain G. (Copenhagen, DK)
Restat, Christophe A. (Austin, TX, US)
Pasquarette, John A. (Austin, TX, US)
Fletcher, Clinton J. (Pflugerville, TX, US)

Plaque It!

PRIORITY DATA

This application claims benefit of priority of U.S. provisional application Ser. No. 60/495,478, titled “Mixed Signal Workbench”, filed Aug. 15, 2003, and whose inventors were Michael L. Santori, J. Clinton Fletcher, Alain G. Moriat, Philippe G. Joffrain, Christophe A. Restat, Christopher G. Cifra, John A. Pasquarette, and Richard Keene.

This application also claims benefit of priority of U.S. provisional application Ser. No. 60/496,318, titled “A Mixed Signal Analysis System and Method of Use”, filed Aug. 19, 2003, and whose inventors were Michael L. Santori, J. Clinton Fletcher, Alain G. Moriat, Philippe G. Joffrain, Christophe A. Restat, Christopher G. Cifra, John A. Pasquarette, and Richard Keene.

Claims:

We claim:

1. A memory medium which stores program instructions for displaying signals, wherein the program instructions are executable to implement: displaying a default display tool, wherein the default display tool is operable to display signals of a default data type; receiving first user input requesting display of a first signal; programmatically analyzing the first signal in response to the first user input, including determining a data type of the signal; programmatically determining a display tool operable to display the first signal based on said analyzing, wherein the display tool is programmatically determined based on the determined data type, said programmatically determining comprising: selecting the default display tool as the display tool if the determined data type is compatible with the default data type; and if the determined data type is not compatible with the default data type, determining a replacement display tool operable to display signals of the determined data type; and selecting the replacement display tool as the display tool; and displaying the first signal in the display tool.

2. The memory medium of claim 1, wherein the program instructions are further executable to implement: displaying a Graphical User Interface (GUI); wherein said receiving first user input comprises receiving said first user input to the GUI; and wherein said displaying the first signal in the display tool comprises displaying the first signal in the GUI.

3. The memory medium of claim 2, wherein the GUI is comprised in a signal analysis function development environment.

4. The memory medium of claim 1, wherein the first signal comprises signal data.

5. The memory medium of claim 4, wherein the signal data comprise signal plot data, and wherein the display tool comprises a graph.

6. The memory medium of claim 4, wherein the signal data comprise tabular data, and wherein the display tool comprises a table.

7. The memory medium of claim 4, wherein the display tool comprises an indicator operable to display the signal data.

8. The memory medium of claim 1, wherein said programmatically determining the display tool based on the determined data type comprises: performing a table look-up based on the determined data type to determine the display tool.

9. The memory medium of claim 1, wherein the data type of the signal comprises one or more of: time-domain; frequency-domain; and spatial-domain.

10. The memory medium of claim 1, wherein the data type of the signal comprises one or more of: integer; floating point; Boolean.

11. The memory medium of claim 1, wherein the data type of the signal comprises a user-defined data type.

12. The memory medium of claim 11, wherein the display tool comprises a user-defined display tool.

13. The memory medium of claim 1, wherein said determining the replacement display tool comprises creating the replacement display tool.

14. The memory medium of claim 1, wherein said receiving first user input requesting display of a first signal comprises: a user dragging and dropping a signal icon corresponding to the first signal onto the default display tool.

15. The memory medium of claim 1, wherein the program instructions are further executable to implement: receiving second user input requesting display of a new display tool; displaying the default display tool in response to the second user input, wherein the default display tool is operable to display signal data of the default data type; receiving third user input requesting display of a second signal, programmatically analyzing the second signal in response to said third user input to determine a data type of the second signal; and if the determined data type of the second signal is compatible with the default data type, displaying the second signal in the default display tool; and if the determined data type is not compatible with the default data type, replacing the default display tool with a second replacement display tool operable to display the second signal; and displaying the second signal in the second replacement display tool.

16. A method for displaying signals, comprising: displaying a default display tool, wherein the default display tool is operable to display signals of a default data type; receiving first user input requesting display of a first signal; programmatically analyzing the first signal in response to the first user input, including determining a data type of the signal; programmatically determining a display tool operable to display the first signal based on said analyzing, wherein the display tool is programmatically determined based on the determined data type, said programmatically determining comprising: using the default display tool as the display tool if the determined data type is compatible with the default data type; and if the determined data type is not compatible with the default data type, determining a replacement display tool operable to display signals of the determined data type; and using the replacement display tool as the display tool; and displaying the first signal in the display tool.

17. A system for displaying signals, comprising: a processor; and a memory coupled to the processor, wherein the memory stores program instructions for specifying a signal analysis function, wherein the program instructions are executable by the processor to: display a default display tool, wherein the default display tool is operable to display signals of a default data type; receive first user input requesting display of a first signal; programmatically analyze the first signal in response to the first user input, including determining a data type of the signal; programmatically determine a display tool operable to display the first signal based on said analyzing, wherein the display tool is programmatically determined based on the determined data type, comprising: select the default display tool as the display tool if the determined data type is compatible with the default data type; and if the determined data type is not compatible with the default data type; determine a replacement display tool operable to display signals of the determined data type; and select the replacement display tool as the display tool; and display the first signal in the display tool.

18. A system for displaying signals, comprising: means for displaying a default display tool, wherein the default display tool is operable to display signals of a default data type; means for receiving first user input requesting display of a first signal; means for programmatically analyzing the first signal in response to the first user input, including means for determining a data type of the signal; means for programmatically determining a display tool operable to display the first signal based on said analyzing, including means for programmatically determining the display tool based on the determined data type, comprising: means for selecting the default display tool as the display tool if the determined data type is compatible with the default data type; and means for determining a replacement display tool operable to display signals of the determined data type and replacing the default display tool with the replacement display tool, if the determined data type is not compatible with the default data type; and means for displaying the first signal in the display tool.

19. A memory medium which stores program instructions for displaying signals, wherein the program instructions are executable to implement: displaying a first display tool, wherein the first display tool displays a prior signal of a first data type; receiving first user input requesting display of a first signal; programmatically analyzing the first signal in response to the first user input, including determining a data type of the signal; programmatically determining a display tool operable to display the first signal based on said analyzing, wherein the display tool is programmatically determined based on the determined data type, said programmatically determining comprising: selecting a default display tool as the display tool if the determined data type is compatible with a default data type; and if the determined data type is not compatible with the default data type, determining a replacement display tool operable to display signals of the determined data type; and selecting the replacement display tool as the display tool; and displaying the first signal in the determined display tool.

20. The memory medium of claim 19, wherein said displaying the first signal in the display tool comprises: if the determined data type is compatible with the first data type, displaying the first signal in the first display tool with the prior signal; and if the determined data type is not compatible with the first data type, displaying a second display tool; and displaying the first signal in the second display tool.

21. The memory medium of claim 20, wherein said determining the second display tool comprises creating the second display tool.

22. The memory medium of claim 19, wherein said receiving first user input requesting display of a first signal comprises: a user dragging and dropping a signal icon corresponding to the first signal onto the first display tool.

23. A memory medium which stores program instructions for displaying signals, wherein the program instructions are executable to implement: displaying a plurality of display tools, wherein the plurality of display tools correspond respectively to a plurality of data types, and wherein each display tool displays one or more respective signals of a respective data type of the plurality of data types; receiving first user input requesting display of a first signal; programmatically analyzing the first signal in response to the first user input, including determining a data type of the signal; programmatically determining a display tool operable to display the first signal based on said analyzing, wherein the display tool is programmatically determined based on the determined data type, said programmatically determining comprising: programmatically determining if the plurality of display tools comprises a matching display tool operable to display signals of a data type compatible with the determined data type; if the plurality of display tools comprises the matching display tool, selecting the matching display tool as the display tool; and if the plurality of display tools does not comprise the matching display tool, determining a second display tool operable to display signals of the determined data type, and selecting the second display tool as the display tool; and displaying the first signal in the display tool.

24. The memory medium of claim 23, wherein said displaying the first signal in the display tool comprises: if the plurality of display tools comprises the matching display tool, displaying the first signal in the matching display tool; and if the plurality of display tools does not comprise the matching display tool, displaying the second display tool; and displaying the first signal in the second display tool.

25. A memory medium which stores program instructions for displaying signals, wherein the program instructions are executable to implement: receiving first user input requesting display of a first signal; programmatically analyzing the first signal in response to the first user input; programmatically determining a display tool operable to display the first signal based on said analyzing; and displaying the first signal in the display tool; receiving second user input requesting display of a new display tool; displaying a default display tool in response to the second user input, wherein the default display tool is operable to display signal data of a default data type; receiving third user input requesting display of a second signal, programmatically analyzing the second signal in response to said third user input to determine a data type of the second signal; and if the determined data type of the second signal is compatible with the default data type, displaying the second signal in the default display tool; and if the determined data type is not compatible with the default data type, replacing the default display tool with a replacement display tool operable to display the second signal; and displaying the second signal in the replacement display tool.

Description:

FIELD OF THE INVENTION

The present invention relates to the field of signal analysis, and more particularly to a system and method for interactively specifying and performing signal analysis functions.

DESCRIPTION OF THE RELATED ART

Traditionally, high level text-based programming languages have been used by programmers in writing application programs. Many different high level text-based programming languages exist, including BASIC, C, C++, Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level text-based languages are translated to the machine language level by translators known as compilers or interpreters. The high level text-based programming languages in this level, as well as the assembly language level, are referred to herein 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. 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, 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'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 conceptualize a problem or process and then to program a computer to implement a solution to the problem or process. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his solution, the efficiency with which the computer system can be utilized often is reduced.

To overcome the above shortcomings, various graphical programming environments now exist which allow a user to construct a graphical program or graphical diagram, also referred to as a block diagram. 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 programming environment which enables a user to easily and intuitively create a graphical program. Graphical programming environments such as that 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.

A user may assemble a graphical program by selecting various icons or nodes which represent desired functionality, and then connecting the nodes together to create the program. The nodes or icons may be connected by lines representing data flow between the nodes, control flow, or execution flow. Thus 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.

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 output that will be used by the graphical program, and may include other icons which represent devices being controlled.

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, modeling, simulation, image processing/machine vision applications, and motion control, among others.

In parallel with the development of the graphical programming model, increasingly, much of the instrumentation related to the above fields of application, e.g., test and measurement, data acquisition, process control, etc., has been implemented as virtual instruments (VIs). A virtual instrument is a user-defined measurement and automation system that includes a computer (such as a standard personal computer) or workstation equipped with the application software (such as LabVIEW graphical programs), hardware (such as DAQ boards, or more specialized hardware boards, e.g., oscilloscope boards, arbitrary waveform generator boards, etc.), and driver software. Virtual instrumentation represents a fundamental shift from traditional hardware-centered instrumentation systems to software-centered systems that exploit the computational, display, productivity and connectivity capabilities of computers, networks and the Internet. Because virtual instruments exploit these computation, connectivity, and display capabilities, users can define and change the functionality of their instruments, rather than being restricted by fixed-functions imposed by traditional instrument vendors. Virtual instruments may be used to monitor and control traditional instruments, create computer-based systems that can replace traditional instruments at a lower cost, and develop systems that integrate measurement functionality with industrial automation. Additionally, giving users flexibility to create their own user-defined virtual instruments for an increasing number of applications in a wide variety of industries, and letting users leverage the latest technologies from computers, networking and communications generally shortens system development time and reduces both short- and long-term costs of developing, owning and operating measurement and automation systems, and may generally improve efficiency and precision of applications spanning research, design, production and service.

Virtual instruments may thus effectively replace many traditional standalone hardware-based instruments, such as, for example, oscilloscopes, multi-meters, and so forth. Such virtual instruments provide a number of benefits over their hardware equivalents, such as, for example, lower cost of manufacture and distribution and ease of upgrades, among others. An exemplary virtual instrument system is the National Instruments' LabVIEW system, where, for example, graphical interfaces or “front ends” of various instruments, such as oscilloscopes, multi-meters, and arbitrary waveform generators, execute on a host computer system, often in conjunction with data acquisition (DAQ) hardware or other specialized boards, e.g., oscilloscope boards, multi-meter boards, and arbitrary waveform generator boards, etc., to provide respective functionality traditionally provided by standalone hardware devices. In some virtual instruments, some or all of the instrument functionality is implemented in software and executed on the host computer. Thus, a virtual instrument may be implemented completely in software (e.g., a “soft-scope”), or may implemented in both software and hardware, in contrast with traditional standalone hardware instruments.

In some signal analysis applications, such as test and measurement, control, simulation, equipment design, etc., numerous instruments may be required to analyze various signals related to the application. The coordinated configuration and use of these instruments to perform the desired tasks of the application generally requires significant effort, e.g., custom programming and/or coordinated configuration of the devices, and thus is often tedious, time-consuming, and error prone. Thus, improved systems and methods for specifying and performing signal analysis functions are desired.

Many applications use or manipulate multiple types of data, e.g., time-domain waveforms, frequency-domain waveforms, digital-domain waveforms, xy-pairs, and scalars, among others. There may be different ways of viewing these different data types. For example, a time-domain waveform typically cannot not be viewed on the same display tool, e.g., on the same graph, as a frequency-domain waveform.

One solution is to have multiple display tools (e.g., graphs) displayed in the GUI allowing a user to view respective data types on each. However, if one display tool of each type is already present on the screen ready for use, each display tool must be fairly small since monitor display space is limited and there is a great possibility that not all display tools will be used, as any given project may not generate all data types. One approach is to have the user request a display tool of a specific type as needed. The application would thus launch either with a default display tool visible or no display tool at all, and based on the user's needs would present a new replacement or additional display tool to view some signals. However, this approach places the burden of display tool choice on the user, and may result in errors, e.g., the user requesting an incompatible display tool by mistake or due to lack of knowledge. Thus, improved systems and methods for presenting data, e.g., signal data, to a user are desired.

SUMMARY OF THE INVENTION

Various embodiments of a system and method for automatically displaying signals are described. In one embodiment, a graphical user interface (GUI), e.g., of a signal analysis function development environment, may include various display tools for displaying a plurality of data types to the user, e.g., via graphs, tables or other formats, as needed. The display tools, e.g., graphs and tables, also referred to as “automatic display tools”, “smart display tools”, or “smart graphs”, may automatically distinguish between different data types and may present the data in a manner commensurate with the data's type. For example, when display of a signal is requested, e.g., by an application or by the user, the burden of choice among display types may be removed from the user and the appropriate display tool created or selected automatically by the application to view the signal. In one embodiment, exceptions to this automatic functionality may be handled manually, e.g., by the user. Note that although the embodiments described below are presented in the context of a signal analysis function development environment, the display tool techniques described herein are broadly applicable to data display in other application domains and tools. For brevity, the term “application” is used below to refer to the software environment in which the method described below is performed.

In one embodiment, a default display tool may be displayed which is operable to display signal data of a default data type, and may comprise a graph for displaying signal plots, or, alternatively, may comprise a (blank) table for displaying tabular data. In one embodiment, the default display tool may be displayed in response to user input, e.g., invoking generic data display functionality in the application. In a preferred embodiment, the application may launch with the default display tool visible.

In one embodiment, a GUI display of the signal analysis function development environment may represent a specified signal analysis function by a set of function blocks. For example, in one example embodiment, two basic function waveforms may be provided by respective Basic Function function blocks, and power spectra for the waveforms generated by respective Power Spectrum function blocks. In one embodiment where a default display tool is displayed, the default display tool may take up substantially the entire viewing area of the GUI. In this example embodiment, the default display tool may be a time-domain graph for displaying time-domain signal plots.

First user input may be received requesting display of a first signal. The user input may be received in a variety of ways. For example, in a preferred embodiment, the user may “drag and drop” a signal icon corresponding to the first signal onto the default graph, as described earlier. In another embodiment, the user may right-click on the signal icon to invoke various options related to the signal, and may select a “display” option or equivalent. In yet another embodiment, the user may right-click on the default graph to invoke a list or menu of signals from which the first signal may be selected. Other means of requesting display of the first signal are also contemplated.

The first signal may be programmatically analyzed in response to the first user input. In a preferred embodiment, the first signal may be programmatically analyzed to determine a data type of the first signal. Note that as used herein, the term “data type” may refer to broad signal types, such as time-domain data (values vs. time), frequency domain data (values vs. frequency), and spatial-domain data (x vs. y), and may also refer to programming data types, such as, for example, integer, floating point, and Boolean data, including arrays or vectors of such data, among others. In one embodiment, user-defined data types may also be accommodated. For example, the user may define various “custom” data types, and may also specify or provide respective display tools for displaying data of these user-defined types.

A display tool operable to display the first signal may be programmatically determined based on the above analysis. In a preferred embodiment, the display tool may be determined based on the data type of the first signal. For example, in one embodiment, programmatically determining the display tool based on the determined data type may include performing a table look-up based on the determined data type to determine the display tool. In other words, the method may use the determined data type for the first signal to lookup a suitable display tool, i.e., a display tool suitable for displaying signal data of the determined data type.

The first signal may then be displayed in the display tool. Depending upon the data type of the first signal, and the type of the default display tool, the display of the first signal may be performed in different ways. For example, in one embodiment, a determination may be made as to whether the determined display tool is the default display tool, i.e., whether the default display tool is operable to display the first signal. Said another way, a determination may be made as to whether the determined data type is compatible with the default data type, and if the determined data type is compatible with the default data type, the default display tool may be determined to be the display tool, and so the first signal may be displayed in the default display tool.

Following the above example embodiment, if the user has requested display of a time-domain signal, e.g., by dragging and dropping a signal icon onto the default display tool, since the data type of the signal is supported by the default display tool, the signal is displayed by the default display tool, i.e., the default graph is of the correct type for displaying the signal. If the determined display tool is not the default display tool, then the default display tool may be replaced with the determined display tool, and the first signal displayed in the determined display tool. In other words, if the determined data type is not compatible with the default data type, a replacement display tool operable to display signals of the determined data type may be determined, the default display tool replaced with the determined (replacement) display tool, and the first signal displayed in the determined (replacement) display tool. In one embodiment, determining the replacement display tool may include creating the replacement display tool. In other words, the type of display tool may be determined based on the above analysis (e.g., by table lookup), and the display tool programmatically created, e.g., based on a pre-defined specification for that display tool type.

Again, following the above example, if the user has requested display of a frequency-domain signal, e.g., by placing a frequency-domain signal icon on the default display tool, the application may automatically replace the default time-domain graph with a frequency-domain graph, thus providing the correct display tool for the signal of the frequency-domain type without consuming additional screen display space, as only one display tool, i.e., graph, is still presented.

As noted above, in a preferred embodiment, the first signal comprises signal data. Thus, depending upon the type of the signal data, the determined display tool may vary. For example, in an embodiment where the signal data comprise signal plot data, the display tool preferably includes a graph. Note that depending upon the data, the graph may be a 2D graph, a 3D graph, or any other type of graph suitable for displaying the data. In an embodiment where the signal data comprise tabular data, the display tool preferably comprises a table. In cases where the signal data comprises neither plot data or tabular data, the determined display tool may include an indicator operable to display the signal data. For example, if the signal data is a Boolean, a simple Boolean indicator, such as an “LED” type indicator, may be used to present the data (or datum). In cases where the data type of the signal is a user-defined type, user-defined or user-specified display tools may be provided and used as needed.

In some cases, when the user requests display of the signal, there may already be a display tool displayed in the GUI, where the display tool displays one or more prior signals. For example, the method may include displaying a first display tool prior to receiving the first user input, where the first display tool displays a prior signal of a first data type. In one embodiment, programmatically determining the display tool may include: if the determined data type is compatible with the first data type, determining that the first display tool comprises the display tool, and if the determined data type is not compatible with the default data type, determining a second display tool operable to display signals of the determined data type. Thus, displaying the first signal in the display tool may include: if the determined data type is compatible with the first data type, displaying the first signal in the first display tool with the prior signal, and if the determined data type is not compatible with the first data type, displaying the second display tool, and displaying the first signal in the second display tool.

The above situation may be extended to multiple prior signal displays, where for example, in one embodiment, a plurality of display tools may be displayed prior to receiving the first user input, where the plurality of display tools correspond respectively to a plurality of data types, and where each display tool displays one or more respective signals of a respective data type of the plurality of data types. Programmatically determining the display tool may thus include programmatically determining if the plurality of display tools includes a matching display tool operable to display signals of a data type compatible with the determined data type, and if the plurality of display tools comprises a matching display tool, determining that the matching display tool comprises the display tool, and if the plurality of display tools does not include a matching display tool, determining a second display tool operable to display signals of the determined data type, wherein the second display tool comprises the display tool.

Similarly, displaying the first signal in the display tool may include: if the plurality of display tools comprises a matching display tool displaying the first signal in the matching display tool, and if the plurality of display tools does not comprise a matching display tool, displaying the second display tool, and displaying the first signal in the second display tool.

Thus, in one embodiment, the method described above may be performed iteratively, where additional or successive signals may be respectively displayed on prior display tools if they support the data types of the signals, or, in cases where the data types of the signals are not supported by the prior display tools, further display tools determined (and optionally created) for display of the signals.

Since a new display tool is not automatically determined (or optionally created) unless a type conflict is generated by a user requesting display of a signal on an incompatible display tool, a manual way of adding a display tool within the application may be provided. In one embodiment, the user may manually request a display tool. For example, in one embodiment, once the first signal is displayed, second user input requesting display of a new display tool may be received. A default display tool may be displayed in response to the second user input, where the default display tool is operable to display signal data of a default data type, as described above.

Third user input requesting display of a second signal may then be received, e.g., by dragging and dropping a signal icon onto the default display tool. The second signal may be programmatically analyzed in response to the third user input to determine a data type of the second signal, and if the determined data type of the second signal is compatible with the default data type, the second signal may be displayed in the default display tool (as described above). If, on the other hand, the determined data type is not compatible with the default data type, the default display tool may be replaced with a replacement display tool operable to display the second signal (as also described above) and the second signal displayed in the replacement display tool.

Thus, in the event that the default display tool (or any prior display tool) is already displaying signals of a different type than currently requested, no replacement may take place, but an additional display tool may be displayed (and optionally created) of the appropriate type, and the requested signal displayed therein. Said another way, upon requesting a new display tool, a new instance of the default display tool may be determined and provided (and optionally created). If the user requests display of an incompatible signal, e.g., places an incompatible data type on the new unused default display tool instance, the application may automatically replace it with the appropriate display tool instance. It is important to note that multiple signals may be viewed on the same graph, as long as the types of the signals are compatible.

Thus, various embodiments of the system and method described above may facilitate automatic presentation of signal data in an appropriate display tool, e.g., a graph, table, indicator, or other type of display tool, based on the signal data, e.g., based on the data type of the signal.

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. 1A illustrates a computer system operable to execute a graphical program according to an embodiment of the present invention;

FIG. 1B illustrates a network system comprising two or more computer systems that may implement an embodiment of the present invention;

FIG. 2A illustrates an instrumentation control system according to one embodiment of the invention;

FIG. 2B illustrates an industrial automation system according to one embodiment of the invention;

FIG. 3A is a high level block diagram of an exemplary system which may execute or utilize programs according to embodiments of the invention;

FIG. 3B illustrates an exemplary system that may perform control and/or simulation functions;

FIG. 4 is an exemplary block diagram of the computer systems of FIGS. 1A, 1 B, 2 A and 2 B and 3 B;

FIG. 5 is a flowchart diagram illustrating one embodiment of a method for specifying a signal analysis function;

FIG. 6 illustrates an example graphical user interface for specifying and performing signal analysis functions, according to one embodiment;

FIG. 7 is a block diagram of an exemplary hardware setup suitable for performing a signal analysis function, according to one embodiment;

FIGS. 8A-8G illustrate an example walk-through of an exemplary signal analysis function specification and performance, according to one embodiment;

FIGS. 8H and 8I illustrate further examples and use of function blocks, according to one embodiment;

FIG. 9 is a data flow diagram of the example system and process of FIGS. 8A-8G, according to one embodiment;

FIG. 10 flowcharts one embodiment of a method for automatically configuring function blocks of a signal analysis function, according to one embodiment;

FIGS. 11A and 11B are flowchart diagrams illustrating embodiments of a method for specifying and performing a sweep as part of a signal analysis function;

FIGS. 12A-12D illustrate an embodiment of a graphical user interface for performing the methods of FIGS. 11A and 11B;

FIGS. 13A-13H illustrate another embodiment of a graphical user interface for performing the methods of FIGS. 11A and 11B;

FIG. 14 flowcharts one embodiment of a method for automatically displaying signal data based on signal type, according to one embodiment;

FIGS. 15A-15F illustrate automatically displaying signal data based on signal type, according to various embodiments;

FIG. 16A is a block diagram of a virtual interactive instruments architecture, according to one embodiment;

FIG. 16B flowcharts one embodiment of a method of use for the system of FIG. 16A; and

FIGS. 17A-17G illustrate various embodiments of an example soft front panel.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Incorporation by Reference

The following references are hereby incorporated by reference in their entirety as though fully and completely set forth herein:

U.S. provisional application Ser. No. 60/495,478, titled “Mixed Signal Workbench”, filed Aug. 15, 2003.

U.S. provisional application Ser. No. 60/496,318, titled “A Mixed Signal Analysis System and Method of Use”, filed Aug. 19, 2003.

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. 5,481,741 titled “Method and Apparatus for Providing Attribute Nodes in a Graphical Data Flow Environment”.

U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System” filed Aug. 18, 1997.

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,” filed Aug. 18, 1997.

U.S. Patent Application Publication No. 20010020291 (Ser. No. 09/745,023) titled “System and Method for Programmatically Generating a Graphical Program in Response to Program Information,” filed Dec. 20, 2000.

U.S. patent application Ser. No. 09/886,496, titled “System and Method for Programmatically Creating Graphical Program Code in a Graphical Program”, filed Jun. 20, 2001.

Terms

The following is a glossary of terms used in the present application:

Memory Medium—Any of various types of memory devices or storage devices. The term “memory medium” is intended to include an installation medium, e.g., a CD-ROM, floppy disks 104 , or tape device; a computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile memory such as a magnetic media, e.g., a hard drive, or optical storage. The memory medium may comprise other types of memory as well, or combinations thereof. In addition, the memory medium may be located in a first computer in which the programs are executed, or may be located in a second different computer which connects to the first computer over a network, such as the Internet. In the latter instance, the second computer may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory mediums which may reside in different locations, e.g., in different computers that are connected over a network.

Carrier Medium—a memory medium as described above, as well as signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a bus, network and/or a wireless link.

Programmable Hardware Element—includes 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. A programmable hardware element may also be referred to as “reconfigurable logic”.

Medium—includes one or more of a memory medium, carrier medium, and/or programmable hardware element; encompasses various types of mediums that can either store program instructions/data structures or can be configured with a hardware configuration program.

Program—the term “program” is intended to have the full breadth of its ordinary meaning. The term “program” includes 1) a software program which may be stored in a memory and is executable by a processor or 2) a hardware configuration program useable for configuring a programmable hardware element.

Software Program—the term “software program” is intended to have the full breadth of its ordinary meaning, and includes any type of program instructions, code, script and/or data, or combinations thereof, that may be stored in a memory medium and executed by a processor. Exemplary software programs include programs written in text-based programming languages, such as C, C++, Pascal, Fortran, Cobol, Java, assembly language, etc.; graphical programs (programs written in graphical programming languages); assembly language programs; programs that have been compiled to machine language; scripts; and other types of executable software. A software program may comprise two or more software programs that interoperate in some manner.

Hardware Configuration Program—a program, e.g., a netlist or bit file, that can be used to program or configure a programmable hardware element.

Graphical Program—A program comprising a plurality of interconnected nodes or icons, wherein the plurality of interconnected nodes or icons visually indicate functionality of the program.

The following provides examples of various aspects of graphical programs. The following examples and discussion are not intended to limit the above definition of graphical program, but rather provide examples of what the term “graphical program” encompasses:

The nodes in a graphical program may be connected in one or more of a data flow, control flow, and/or execution flow format. The nodes may also be connected in a “signal flow” format, which is a subset of data flow.

Exemplary graphical program development environments which may be used to create graphical programs include LabVIEW, DasyLab, DiaDem and Matrixx/SystemBuild from National Instruments, Simulink from the MathWorks, VEE from Agilent, WiT from Coreco, Vision Program Manager from PPT Vision, SoftWIRE from Measurement Computing, Sanscript from Northwoods Software, Khoros from Khoral Research, SnapMaster from HEM Data, Vis Sim from Visual Solutions, ObjectBench by SES (Scientific and Engineering Software), and VisiDAQ from Advantech, among others.

The term “graphical program” includes models or block diagrams created in graphical modeling environments, wherein the model or block diagram comprises interconnected nodes or icons that visually indicate operation of the model or block diagram; exemplary graphical modeling environments include Simulink, SystemBuild, Vis Sim, Hypersignal Block Diagram, etc.

A graphical program may be represented in the memory of the computer system as data structures and/or program instructions. The graphical program, e.g., these data structures and/or program instructions, may be compiled or interpreted to produce machine language that accomplishes the desired method or process as shown in the graphical program.

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, a database, 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.

A graphical program may optionally have a GUI associated with the graphical program. In this case, the plurality of interconnected nodes are often referred to as the block diagram portion of the graphical program.

Node—In the context of a graphical program, an element that may be included in a graphical program. A node may have an associated icon that represents the node in the graphical program, as well as underlying code or data that implements functionality of the node. Exemplary nodes include function nodes, terminal nodes, structure nodes, etc. Nodes may be connected together in a graphical program by connection icons or wires.

Data Flow Graphical Program (or Data Flow Diagram)—A graphical program or diagram comprising a plurality of interconnected nodes, wherein the connections between the nodes indicate that data produced by one node is used by another node.

Graphical User Interface—this term is intended to have the full breadth of its ordinary meaning. The term “Graphical User Interface” is often abbreviated to “GUI”. A GUI may comprise only one or more input GUI elements, only one or more output GUI elements, or both input and output GUI elements.

The following provides examples of various aspects of GUIs. The following examples and discussion are not intended to limit the ordinary meaning of GUI, but rather provide examples of what the term “graphical user interface” encompasses:

A GUI may comprise a single window having one or more GUI Elements, or may comprise a plurality of individual GUI Elements (or individual windows each having one or more GUI Elements), wherein the individual GUI Elements or windows may optionally be tiled together.

A GUI may be associated with a graphical program. In this instance, various mechanisms may be used to connect GUI Elements in the GUI with nodes in the graphical program. For example, when Input Controls and Output Indicators are created in the GUI, corresponding nodes (e.g., terminals) may be automatically created in the graphical program or block diagram. Alternatively, the user can place terminal nodes in the block diagram which may cause the display of corresponding GUI Elements front panel objects in the GUI, either at edit time or later at run time. As another example, the GUI may comprise GUI Elements embedded in the block diagram portion of the graphical program.

Front Panel—A Graphical User Interface that includes input controls and output indicators, and which enables a user to interactively control or manipulate the input being provided to a program, and view output of the program, while the program is executing.

A front panel is a type of GUI. A front panel may be associated with a graphical program as described above.

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.

Graphical User Interface Element—an element of a graphical user interface, such as for providing input or displaying output. Exemplary graphical user interface elements comprise input controls and output indicators

Input Control—a graphical user interface element for providing user input to a program. Exemplary input controls comprise dials, knobs, sliders, input text boxes, etc.

Output Indicator—a graphical user interface element for displaying output from a program. Exemplary output indicators include charts, graphs, gauges, output text boxes, numeric displays, etc. An output indicator is sometimes referred to as an “output control”.

Computer System—any of various types of computing or processing systems, including a personal computer system (PC), mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television system, grid computing system, or other device or combinations of devices. In general, the term “computer system” can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

Measurement Device—includes instruments, data acquisition devices, smart sensors, and any of various types of devices that are operable to acquire and/or store data. A measurement device may also optionally be further operable to analyze or process the acquired or stored data. Examples of a measurement device include an instrument, such as a traditional stand-alone “box” instrument, a computer-based instrument (instrument on a card) or external instrument, a data acquisition card, a device external to a computer that operates similarly to a data acquisition card, a smart sensor, one or more DAQ or measurement cards or modules in a chassis, an image acquisition device, such as an image acquisition (or machine vision) card (also called a video capture board) or smart camera, a motion control device, a robot having machine vision, and other similar types of devices. Exemplary “stand-alone” instruments include oscilloscopes, multimeters, signal analyzers, arbitrary waveform generators, spectroscopes, and similar measurement, test, or automation instruments.

A measurement device may be further operable to perform control functions, e.g., in response to analysis of the acquired or stored data. For example, the measurement device may send a control signal to an external system, such as a motion control system or to a sensor, in response to particular data. A measurement device may also be operable to perform automation functions, i.e., may receive and analyze data, and issue automation control signals in response. A measurement device may further be operable to perform modeling or simulation functions, e.g., for use in design or testing procedures.

FIG. 1 A—Computer System

FIG. 1A illustrates a computer system 82 operable to execute software programs according to various embodiments of the present invention. Various embodiments of a method for specifying and performing a signal analysis function are described below. It should be noted that as used herein, the term “signal analysis function” refers to any type of function that relates to the generation, acquisition, and/or analysis of signals, e.g., for measurement, testing, control, simulation or modeling, design, prototyping, and so forth.

As shown in FIG. 1A, the computer system 82 may include a display device operable to display signal analysis results as the signal analysis function is created and/or executed. The display device may also be operable to display a graphical user interface during execution of the program. The graphical user interface may comprise any type of graphical user interface, e.g., depending on the computing platform.

The computer system 82 may include a memory medium(s) on which one or more computer programs or software components according to one embodiment of the present invention may be stored. For example, the memory medium may store one or more programs, e.g., graphical programs, which are executable to perform the methods described herein. For example, the memory medium may store one or more software programs implementing a signal analysis function development environment, described below in detail, which may facilitate interactive specification, development, and execution of signal analysis functions. More specifically, the signal analysis function development environment may provide an integrated interface for a plurality of instruments for signal analysis, described below. Also, the memory medium may store a graphical programming environment used to create and/or execute such graphical programs. The memory medium may also store operating system software, as well as other software for operation of the computer system. Various embodiments further include receiving or storing instructions and/or data implemented in accordance with the foregoing description upon a carrier medium.

FIG. 1 B—Computer Network

FIG. 1B illustrates a system including a first computer system 82 that is coupled to a second computer system 90 . The computer system 82 may be connected through a network 84 (or a computer bus) to the second computer system 90 . The computer systems 82 and 90 may each be any of various types, as desired. The network 84 can also be any of various types, including a LAN (local area network), WAN (wide area network), the Internet, or an Intranet, among others. The computer systems 82 and 90 may execute a program, e.g., a graphical program, in a distributed fashion. For example, computer 82 may execute a first portion of the block diagram of a graphical program and computer system 90 may execute a second portion of the block diagram of the graphical program. As another example, computer 82 may display the graphical user interface of a graphical program and computer system 90 may execute the block diagram of the graphical program.

In one embodiment, the graphical user interface of the graphical program may be displayed on a display device of the computer system 82 , and the block diagram may execute on a device 190 connected to the computer system 82 . The device 190 may include a programmable hardware element and/or may include a processor and memory medium which may execute a real time operating system. In one embodiment, the graphical program may be downloaded and executed on the device 190 . For example, an application development environment with which the graphical program is associated may provide support for downloading a graphical program for execution on the device in a real time system.

Exemplary Systems

Embodiments of the present invention may be involved with performing test and/or measurement functions; controlling and/or modeling instrumentation or industrial automation hardware; modeling and simulation functions, e.g., modeling or simulating a device or product being developed or tested, etc. Exemplary test applications where embodiments of the present invention may be used include hardware-in-the-loop testing and rapid control prototyping, among others.

However, it is noted that the present invention can be used for a plethora of applications and is not limited to the above applications. In other words, applications discussed in the present description are exemplary only, and the present invention may be used in any of various types of systems. Thus, the system and method of the present invention is operable to be used in any of various types of applications, including the control of other types of devices such as multimedia devices, video devices, audio devices, telephony devices, Internet devices, etc., as well as general purpose software applications such as word processing, spreadsheets, network control, network monitoring, financial applications, games, etc. In other words, various embodiments of the present invention are contemplated for use in any field of application where signals are analyzed.

FIG. 2A illustrates an exemplary instrumentation control system 100 which may implement embodiments of the invention. The system 100 comprises a host computer 82 which connects to one or more instruments. The host computer 82 may comprise a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 82 may operate with the one or more instruments to analyze, measure or control a unit under test (UUT) or process 150 . As will be described in detail below, in a preferred embodiment, the computer 82 may execute software that utilizes various virtual instruments (VIs), possibly in conjunction with hardware devices (e.g., boards) and/or instruments coupled to the computer, to analyze signals related to an application, device, or phenomenon.

The one or more instruments may include a GPIB instrument 112 and associated GPIB interface card 122 , a data acquisition board 114 and associated signal conditioning circuitry 124 , a VXI instrument 116 , a PXI instrument 118 , a video device or camera 132 and associated image acquisition (or machine vision) card 134 , a motion control device 136 and associated motion control interface card 138 , and/or one or more computer based instrument cards 142 , among other types of devices. The computer system may couple to and operate with one or more of these instruments. The instruments may be coupled to a unit under test (UUT) or process 150 , or may be coupled to receive field signals, typically generated by transducers. The system 100 may be used in a data acquisition and control application, in a test and measurement application, an image processing or machine vision application, a process control application, a man-machine interface application, a simulation or modeling application, or a hardware-in-the-loop validation application, among others.

FIG. 2B illustrates an exemplary industrial automation system 160 which may implement embodiments of the invention. The industrial automation system 160 is similar to the instrumentation or test and measurement system 100 shown in FIG. 2A. Elements which are similar or identical to elements in FIG. 2A have the same reference numerals for convenience. The system 160 may comprise a computer 82 which connects to one or more devices or instruments. The computer 82 may comprise a CPU, a display screen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 82 may operate with the one or more devices to a process or device 150 to perform an automation function, such as MMI (Man Machine Interface), SCADA (Supervisory Control and Data Acquisition), portable or distributed data acquisition, process control, advanced analysis, or other control, among others.

The one or more devices may include a data acquisition board 114 and associated signal conditioning circuitry 124 , a PXI instrument 118 , a video device 132 and associated image acquisition card 134 , a motion control device 136 and associated motion control interface card 138 , a fieldbus device 170 and associated fieldbus interface card 172 , a PLC (Programmable Logic Controller) 176 , a serial instrument 182 and associated serial interface card 184 , or a distributed data acquisition system, such as the Fieldpoint system available from National Instruments, among other types of devices.

FIG. 3A is a high level block diagram of an exemplary system which may execute or utilize programs, e.g., graphical programs, according to various embodiments of the present invention. FIG. 3A illustrates a general high-level block diagram of a generic control and/or simulation system which comprises a controller 92 and a plant 94 . The controller 92 represents a control system/algorithm the user may be trying to develop. The plant 94 represents the system the user may be trying to control. For example, if the user is designing an ECU for a car, the controller 92 is the ECU and the plant 94 is the car's engine (and possibly other components such as transmission, brakes, and so on.) As shown, a user may create a graphical program that specifies or implements the functionality of one or both of the controller 92 and the plant 94 . For example, a control engineer may use a modeling and simulation tool to create a model (graphical program) of the plant 94 and/or to create the algorithm (graphical program) for the controller 92 . The user may then specify and/or execute a signal analysis function to perform various tests and measurements (analyses) on the model, the controller 92 , and/or the plant 94 , e.g., via one or more software programs implementing various embodiments of the present invention, e.g., via a signal analysis function development environment, described below in detail, which may facilitate interactive specification, development, and execution of signal analysis functions.

FIG. 3B illustrates an exemplary system which may perform control and/or simulation functions. As shown, the controller 92 may be implemented by a computer system 82 or other device (e.g., including a processor and memory medium and/or including a programmable hardware element) that executes or implements a graphical program. In a similar manner, the plant 94 may be implemented by a computer system or other device 144 (e.g., including a processor and memory medium and/or including a programmable hardware element) that executes or implements a graphical program, or may be implemented in or as a real physical system, e.g., a car engine.

In one embodiment of the invention, one or more graphical programs may be created which are used in performing rapid control prototyping. Rapid Control Prototyping (RCP) generally refers to the process by which a user develops a control algorithm and quickly executes that algorithm on a target controller connected to a real system. The user may develop the control algorithm using a graphical program, and the graphical program may execute on the controller 92 , e.g., on a computer system or other device. The computer system 82 may be a platform that supports real time execution, e.g., a device including a processor that executes a real time operating system (RTOS), or a device including a programmable hardware element.

In one embodiment of the invention, one or more graphical programs may be created which are used in performing Hardware in the Loop (HIL) simulation. Hardware in the Loop (HIL) refers to the execution of the plant model 94 in real time to test operation of a real controller 92 . For example, once the controller 92 has been designed, it may be expensive and complicated to actually test the controller 92 thoroughly in a real plant, e.g., a real car. Thus, the plant model (implemented by a graphical program) is executed in real time to make the real controller 92 “believe” or operate as if it is connected to a real plant, e.g., a real engine.

In the embodiments of FIGS. 2A, 2 B, and 3 B above, one or more of the various devices may couple to each other over a network, such as the Internet. In one embodiment, the user operates to select a target device from a plurality of possible target devices for programming or configuration using a graphical program. Thus the user may create a graphical program on a computer and use (execute) the graphical program on that computer or deploy the graphical program to a target device (for remote execution on the target device) that is remotely located from the computer and coupled to the computer through a network.

Graphical software programs which perform data acquisition, analysis and/or presentation, e.g., for measurement, instrumentation control, industrial automation, modeling, or simulation, such as in the applications shown in FIGS. 2A and 2B, may also be referred to as virtual instruments, although as described above, in many cases the software programs may operate in conjunction with hardware, such as DAQ boards or other specialized hardware boards. For example, in one embodiment, one or more of the virtual instruments included in the system may include respective hardware boards that provide hardware based functionality for the virtual instrument. In various embodiments, the boards may be one or both of: a PC expansion board installed in the host computer system, e.g., a PCI card or other type of card; and a card, module, or cartridge that is operable to be inserted into a chassis coupled to the host computer, such as a PXI or GPIB chassis. Of course, any other types of chassis and boards may be used as desired. Such virtual instruments may be used in various embodiments of the present invention to perform signal analysis functions, as described below.

FIG. 4 —Computer System Block Diagram

FIG. 4 is a block diagram representing one embodiment of the computer system 82 and/or 90 illustrated in FIGS. 1A and 1B, or computer system 82 shown in FIG. 2A or 2 B. It is noted that any type of computer system configuration or architecture can be used as desired, and FIG. 4 illustrates a representative PC embodiment. It is also noted that the computer system may be a general purpose computer system, a computer implemented on a card installed in a chassis, or other types of embodiments. Elements of a computer not necessary to understand the present description have been omitted for simplicity.

The computer may include at least one central processing unit or CPU (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, e.g., a Pentium class, a PowerPC processor, a CPU from the SPARC family of RISC processors, as well as others. A memory medium, typically comprising RAM and referred to as main memory, 166 is coupled to the host bus 162 by means of memory controller 164 . The main memory 166 may store one or more software programs implementing various embodiments of the present invention. For example, the main memory 166 may store a signal analysis function development environment, described below in detail, which may facilitate interactive specification, development, and execution of signal analysis functions. More specifically, the signal analysis function development environment may provide an integrated interface for a plurality of instruments for signal analysis, described below. The main memory may also store operating system software, as well as other software for operation of the computer system.

The host bus 162 may be coupled to an expansion or input/output bus 170 by means of a bus controller 168 or bus bridge logic. The expansion bus 170 may be the PCI (Peripheral Component Interconnect) expansion bus, although other bus types can be used. The expansion bus 170 includes slots for various devices such as described above. The computer 82 further comprises a video display subsystem 180 and hard drive 182 coupled to the expansion bus 170 .

As shown, a device 190 may also be connected to the computer. The device 190 may include a processor and memory which may execute a real time operating system. The device 190 may also or instead comprise a programmable hardware element. The computer system may be operable to deploy a graphical program to the device 190 for execution of the graphical program on the device 190 . The deployed graphical program may take the form of graphical program instructions or data structures that directly represents the graphical program. Alternatively, the deployed graphical program may take the form of text code (e.g., C code) generated from the graphical program. As another example, the deployed graphical program may take the form of compiled code generated from either the graphical program or from text code that in turn was generated from the graphical program.

FIG. 5 —Flowchart of a Method for Specifying a Signal Analysis Function

FIG. 5 illustrates a method for interactively specifying a signal analysis function. The method shown in FIG. 5 may be used in conjunction with any of the computer systems or devices shown in the above Figures, among other devices. It should be noted that in various embodiments, some of the steps shown may be performed concurrently, in a different order than shown, or omitted. Additional steps may also be performed as desired. As shown, this method may operate as follows.

First, in 502 , user input may be received specifying an operation, where the operation implements at least a portion of a signal analysis function. For example, in a preferred embodiment, the user input may be received to a graphical user interface (GUI) of a signal analysis function development environment, which, as noted above, may facilitate interactive specification, development, and execution of signal analysis functions. More specifically, the signal analysis function development environment may provide an integrated graphical interface for a plurality of instruments for signal analysis, examples of which are provided below with reference to FIGS. 6 and 8 A- 8 I. As mentioned above, the signal analysis function development environment executes on a computer system that includes a display, i.e., a display device, such as a computer monitor, which operates to display the GUI. The GUI preferably includes a display window or panel for displaying signals and signal analysis results (from the operations). Various examples of operations for signal analysis are provided below.

The user may specify the operation in any of a variety of ways. For example, in one embodiment the user may select (e.g., with a pointing device, such as a mouse) the operation from a menu. For example, a menu of selectable operations may be provided by the signal analysis function development environment, e.g., from a menu bar. In one embodiment, the menu may be invoked from a graphical signal display of the signal analysis function development environment. For example, one or more signals (signal plots), e.g., generated by prior operations, may be displayed in a display window. The user may select a signal (or multiple signals) from the display, e.g., by clicking on the signal plot or a symbol for the signal in a plot legend of the display, upon which the menu may be presented. The user may then select the desired operation from the menu.

In another embodiment the user may select the operation from a palette of function icons, where each function icon represents a respective operation. For example, the user may double click on the icon for the operation, thereby invoking a configuration GUI for the operation through which the user may provide input configuring the operation. As another example, the user may “drag and drop” the icon from the palette onto a diagram, active window, and/or another icon. In one embodiment, each function icon may be associated with or comprised in a respective function block, described below in detail. Similar to above, in one embodiment, the palette may be displayed in response to user input selecting a signal plot or signal icon from a display tool, e.g., a graphical display, of the signal analysis function development environment.

Thus, in one embodiment, user input may be received to the graph (or other display tool) indicating one or more signals displayed in the graph. One or more operation options may then be presented in response, and user input received selecting an operation option from the provided one or more operation options, where the selected operation option indicates an operation to be performed on the indicated one or more signals. In a preferred embodiment, the one or more operation options presented to the user include only operation options appropriate for the selected one or more signals. In other words, the method may use information related to the signals (and optionally, information related to previously specified operations) to filter or otherwise limit the operation options presented to the user. For example, if the graph included a power spectrum for a signal, and the power spectrum plot or icon were selected to invoke the operation options, only those operations suitable for application to a power spectrum may be presented, e.g., determining a strongest frequency, average power, etc.

Thus, in one embodiment, receiving user input specifying an operation may include: receiving user input to the graph indicating one or more signals displayed in the graph, and further receiving user input associating the one or more signals with a first icon of the plurality of icons displayed on the display, where after said associating, the operation represented by the first icon may be performed on the one or more signals.

It is noted that other methods of selecting the operation are also contemplated, such as, for example, the user entering the name of the desired operation into a text entry field, although graphical selection methods are preferred.

Signal Operations

The selectable operations mentioned above may include any type of operation related to signals. For example, the operations contemplated may include: generating one or more signals, e.g., by reading one or more signals from a file, and/or synthesizing one or more signals algorithmically; receiving one or more signals from an external source; sending one or more signals to an external system; analyzing one or more signals and generating results based on the analysis; displaying one or more signals; displaying results of another operation; processing one or more signals, thereby generating one or more modified signals; and storing one or more signals, among others. In other words, the operations may include signal generation, acquisition, analysis, processing, storage, import, export, or transmission, among others. A more detailed list of signal operations is provided below.

Additionally, the operations may utilize various instruments to perform their respective functionalities. As mentioned above, in a preferred embodiment, the signal analysis function development environment provides an integrated interface to a plurality of instruments, where the instruments may include virtual instruments (which may or may not include respective hardware boards), and optionally, standalone hardware instruments. For example, receiving one or more signals from an external source may include receiving one or more signals from a hardware device over a transmission medium and/or from a simulation. As another example, a first operation may generate a test signal, e.g., via a virtual arbitrary waveform generator, and export the signal to an external hardware device, such as a filter. The filter may process (filter) the signal and a resultant (filtered) signal may be received by a second operation, e.g., a virtual oscilloscope, which may then display the resultant signal, e.g., compared with the original test signal. Note that the virtual arbitrary waveform generator and/or the virtual oscilloscope may be implemented solely in software, or may be include both software and a hardware board. Examples of hardware boards contemplated for use in preferred embodiments of the present invention include: an E Series Multifunction DAQ (E-MIO), a High Speed Digitizer (Scope), and a Signal Sources (Arbitrary Waveform & Function Generators), as provided by National Instruments Corporation. In further embodiments, the hardware boards may include one or more of: an S Series Multifunction DAQ (SMIO) board, a High-Speed Digital (DIO) board, and a Digital Multimeter (DMM) board, among others.

Thus, the instruments to which access may be provided by the signal analysis function development environment may include virtual instruments, such as a DAQ (data acquisition) device, a digitizer, an arbitrary waveform generator (arb), a digital I/O device, and a digital multimeter, among others, some of which may include corresponding hardware, such as a DAQ board, scope (digitizer) board, an arb board, a digital I/O board, and a digital multimeter board, etc., as described above, and may optionally also include at least one standalone hardware-based instrument, such as, for example, a standalone oscilloscope, multi-meter, waveform generator, hardware filter, etc.

Thus, the signal analysis function development environment may provide access to a plurality of instruments, where the plurality of instruments includes two or more virtual instruments, and may optionally include one or more standalone hardware devices.

In 504 , the operation may be performed in response to the specifying of 502 . The operation is preferably performed utilizing at least one of the plurality of instruments to perform the operation. Generally the performance of the operation results in some form of output, such as, for example, signal data (a signal) or other resultant data that may then be displayed in a display tool of the GUI, e.g., in a graph (e.g., for signal plots) or in a table (e.g., for tabular scalar data). Examples of signal data displays are provided below with reference to FIGS. 8A-8I. It should be noted that other types of data displays are also contemplated, including, for example, histograms and 3D plots, among others.

It should be further noted that in a preferred embodiment, one or more input signals for the operation may be displayed. More generally, as described below, in a preferred embodiment, the signal analysis function may include a plurality of operations, each of which may include one or more input signals and/or one or more output signals, and so the method may include displaying any of the input and/or output signals, as desired.

In 506 , an icon may be displayed on the display in response to the specifying of 502 , where the icon comprises a graphical representation of the operation, and where the icon is displayed upon the specifying. In other words, once the operation is specified in 502 , the corresponding icon for the operation is displayed.

In 508 , information specifying the operation may be stored. For example, the information may be stored in a data structure, such as a file, or transmitted to another system for storage.

In a preferred embodiment, the steps of 502 - 508 may be repeated a plurality of times to specify the signal analysis function, as indicated in FIG. 5. In other words, the user may interactively specify a plurality of operations, thereby invoking performance of each operation upon its invocation and display of the icon corresponding to the operation. In a preferred embodiment, the operations in the signal analysis function include at least one of 1) generating signals displayed in a graph, and 2) modifying one or more signals displayed in the graph. In another embodiment, the operations in the signal analysis function may also include 3) producing an output based on one or more signals displayed in the graph and/or 4) exporting a signal. Of course, in various embodiments, other display tools than graphs may be used, such as tables for displaying tabular signal data.

In other embodiments, the operations in the signal analysis function may include any or all of the signal operations described above in the Signal Operations section. It should be noted that after each respective operation is specified, the operation is preferably continuously performed during the repeating. In other words, once an operation has been specified, the operation executes in a substantially continuous fashion until removed from the signal analysis function or until the signal analysis function is terminated or paused. Note that in general, the signal operations typically relate to one or more of signal generation, signal acquisition, and signal processing or analysis, although other operations are also contemplated.

In one embodiment, as a result of said repeating, a plurality of icons are displayed on the display representing a plurality of operations, where the plurality of icons are arranged to visually indicate the signal analysis function. In other words, in one embodiment, a diagram including the icons of the specified operations is displayed, where the diagram visually indicates the functionality of the signal analysis function. In various embodiments, the diagram may be one or more of: a linear sequence, a data flow diagram, a tree diagram, and a dependency diagram. Additionally, in a preferred embodiment, repeating the steps above produces a set of stored information representing the plurality of operations in the signal analysis function. In a preferred embodiment, the stored information corresponds to the diagram.

As mentioned above, the method described above is preferably performed by program instructions executing under a signal analysis function development environment. In one embodiment, the set of stored information specifying the plurality of operations is executable in the signal analysis function development environment to perform the signal analysis function. Thus, in one embodiment, the program instructions (executing under the signal analysis function development environment) are further executable to implement executing the set of stored information to perform the signal analysis function. For example, in one embodiment, the set of stored information may comprise a script which is executable under the signal analysis function development environment to perform the signal analysis function.

As FIG. 5 shows, in 510 , the method may optionally generate a program, i.e., executable code, based on the set of stored information, where the generated program implements the signal analysis function, and is executable to perform the signal analysis function. Further details of the programmatic generation of the program are provided below in the section titled Code Generation.

Thus, the specification of the plurality of operations produces the signal analysis function, where the signal analysis function utilizes at least a first plurality of the plurality of instruments, and where the plurality of instruments comprises two or more virtual instruments (VIs). Thus, the memory medium of the host computer may store a plurality of virtual instruments, where each of the virtual instruments is executable on the computer system to implement an instrument function, and where the plurality of operations utilize two or more different ones of the plurality of virtual instruments. For example, in one embodiment, the plurality of virtual instruments may include a signal generator VI, an oscilloscope VI, and a multimeter VI. As noted above, in one embodiment, at least a portion of the plurality of virtual instruments operate in conjunction with respective hardware boards. For example, an oscilloscope VI may include an oscilloscope card (board) that provides hardware for at least a portion of the oscilloscope functionality of the VI.

As also noted above, the plurality of instruments may optionally further include at least one standalone hardware device (instrument). In other words, in addition to the virtual instruments, in some embodiments, the computer may also be coupled to one or more standalone hardware based instruments, such as, for example, a standalone oscilloscope, multi-meter, waveform generator, hardware filter, etc., where one or more of the specified operations may be operable to receive signals from, or provide signals to, one or more of the standalone instruments.

In one embodiment, the method may further include specifying a relationship between a first icon and a second icon, thereby specifying a relationship between a first operation and a second operation, where specifying the relationship between the first icon and the second icon includes specifying that data produced by the first operation is used by the second operation. For example, in one embodiment, the relationship may be specified in response to user input indicating the relationship, e.g., user input indicating, say, that the output of the first operation is provided as input for the second operation, e.g., via drag and drop techniques, the user drawing “wires” between the two icons, right-clicking on an icon and invoking a menu whereby the relationship is specified by user selection, etc.

In another embodiment, the relationship may be performed programmatically, e.g., automatically. For example, in one embodiment, when an operation is specified or selected, prior operations input by the user may be programmatically analyzed to determine an input source for the operation, i.e., to determine a prior operation that provides the appropriate input for the selected operation, e.g., based on chronology, signal type, format, etc. In other words, a heuristic based on one or more attributes of the selected operation and attributes of the prior operations may be used to determine the relationship, e.g., a default relationship, between the specified operation and at least one of the previously specified operations. Of course, once this relationship is determined, the user may modify or replace the determined relationship.

In one embodiment, the relationships between operations or, more specifically, between operation icons, may be visually represented. For example, in one embodiment, each operation icon may display labels or images indicating their respective input and/or output signals. Thus, an I/O relationship between operation A and operation B, where A's output is B's input, may be indicated simply by A's icon including an output icon (e.g., symbol, label, or image) with the label “B”, and B's icon including an input icon with the label “A”.

In one embodiment, the icons or labels may be displayed as part of the icon. In another embodiment, the icons or labels may be displayed only when invoked by the user, e.g., by right-clicking on the icon, hovering the cursor over the icon, and so forth.

Other types of icons are also contemplated. For example, in one embodiment, each operation may have a symbol as well as an icon, where the operation icon displays its own symbol, and where the symbol may also be displayed as input/output signal icons displayed in or by other icons, indicating their respective input/output signals. As another example, similar to the “wires” used to indicate couplings between graphical program nodes in graphical programs, directional lines or graphical vectors may be displayed showing the relationship between operations.

In one embodiment, once an operation has been specified, the user may configure the operations, where, for each operation, configuring the operation affects functionality of the operation. Note that in general, this configuration may occur while previously specified operations (and the present operation) are executing substantially continuously. For example, in one embodiment, during said repeating, user input to one or more of the icons may be received for configuring one or more of the plurality of operations, where receiving user input for configuring one or more of the plurality of operations does not include receiving user input specifying programming language code to configure the operations. In other words, the user preferably does not have to manually program (using a programming language) to configure the operation.

For example, in one embodiment, for each operation to be configured, a graphical panel including one or more graphical user interface elements for setting properties of the operation may be displayed, and user input to the graphical panel received to set one or more properties of the operation. In other words, the user may invoke a configuration GUI for configuring the operation, e.g., by right-clicking on the operation's icon. In another embodiment, the configuration GUI may be displayed automatically, e.g., when the operation is originally specified, when another operation is associated with the operation, e.g., when a relationship between operations is specified or indicated, and so on.

In one embodiment, one or more operations may also be removed from the plurality of operations. For example, in one embodiment, user input may be received specifying removal of a first operation from the plurality of operations. In response to specifying the removal of the operation, the method may include: discontinuing performance of the first operation from the plurality of operations, discontinuing display of the first icon, removing information associated with the first operation from the set of stored information, and modifying one or more signals displayed in the graph, as needed.

Code Generation

As noted above, in one embodiment, the set of stored information may comprise a script or equivalent which is executable under the signal analysis function development environment to perform the signal analysis function. In another embodiment, where the method described above executes under the signal analysis function development environment, a program implementing the plurality of operations may be programmatically generated based on the set of stored information, as noted above in 510 , where the program is executable outside of the signal analysis function development environment. In other words, once the information specifying or representing the set of operations is produced and/or stored, the method may include programmatically generating a corresponding program that may be executed outside the development environment. Thus, the generated program may be saved, exported to other systems, etc., and executed independently of the signal analysis function development environment. In a preferred embodiment, the generated progr

4570217	Man machine interface	February, 1986	Allen et al.
4831580	Program generator	May, 1989	Yamada
4849880	Virtual machine programming system	July, 1989	Bhaskar et al.
5005119	User interactive control of computer programs and corresponding versions of input/output data flow	April, 1991	Rumbaugh et al.
5309556	Method for using interactive computer graphics to control electronic instruments	May, 1994	Sismilich
5371851	Graphical data base editor	December, 1994	Pieper et al.
5461708	Systems and methods for automated graphing of spreadsheet information	October, 1995	Kahn	345/440
5479643	Virtual machine programming system	December, 1995	Bhaskar et al.
5481712	Method and apparatus for interactively generating a computer program for machine vision analysis of an object	January, 1996	Silver et al.
5499373	Apparatus and methods for designing, analyzing or simulating signal processing functions	March, 1996	Richards et al.	715/500.1
5550964	System and methods for intelligent analytical graphing	August, 1996	Davoust	345/440
5630164	Scientific instrument emulator having a computer and an analog signal interface for real-time signal processing	May, 1997	Williams et al.	703/24
5657221	Method and apparatus for controlling non-computer system devices by manipulating a graphical representation	August, 1997	Warman et al.
5748881	Method and apparatus for a real-time data collection and display system	May, 1998	Lewis et al.	714/47
5911070	Development system with methods for bi-directional application program code generation	June, 1999	Solton et al.
5940296	Method and system for interactively developing a graphical control-flow structure and associated application software for use in a machine vision system	August, 1999	Meyer
6061602	Method and apparatus for developing application software for home automation system	May, 2000	Meyer
6167562	Apparatus for creating an animation program and method for creating the same	December, 2000	Kaneko
6172428	Digital control system and method for generator sets	January, 2001	Jordan	290/40C
6222540	User-friendly graphics generator including automatic correlation	April, 2001	Sacerdoti
6226783	Object oriented method of structuring a software step program	May, 2001	Limondin et al.
6288474	Drive detection device for gyroscope	September, 2001	Ono et al.
6298474	Method and system for interactively developing a graphical control-flow structure and associated application software for use in a machine vision system and computer-readable storage medium having a program for executing the method	October, 2001	Blowers et al.
6326987	Graphical system and method for annotating measurements and measurement results in a signal measurement system	December, 2001	Alexander	715/771
6408429	Machine vision system for identifying and assessing features of an article	June, 2002	Marrion, Jr. et al.
6577323	Multivariable process trend display and methods regarding same	June, 2003	Jamieson et al.	715/700
6614433	Method and system for distributed, dynamic generation of graphics files	September, 2003	Watts	345/440
6637022	Enhanced graphical development environment for controlling program flow	October, 2003	Weeren et al.
6763515	System and method for automatically generating a graphical program to perform an image processing algorithm	July, 2004	Vazquez et al.
6839727	System and method for computing a discrete transform	January, 2005	Kechriotis
7146384	System and method for data analysis, manipulation, and visualization	December, 2006	Sawafta	707/104.1
20020118192	Multiple chart user interface	August, 2002	Couckuyt et al.	345/440
20020126151	System and method for graphically creating a sequence of motion control, machine vision, and data acquisition (DAQ) operations	September, 2002	Chandhoke et al.
20020129333	System and method for programmatically generating a graphical program based on a sequence of motion control, machine vision, and data acquisition (DAQ) operations	September, 2002	Chandhoke et al.
20020151992	Media recording device with packet data interface	October, 2002	Hoffberg et al.	700/83
20020186245	System and method for configuring a hardware device to execute a prototype	December, 2002	Chandhoke et al.
20020191023	System and method for graphically creating a sequence of motion control operations	December, 2002	Chandhoke et al.
20030043175	System and method for specifying a machine vision process using dfferent programming methodologies	March, 2003	Vazquez et al.
20030154443	Visual discovery tool	August, 2003	Papierniak et al.	715/502
20030179242	Displaying simultaneously a main waveform display and a magnified waveform display in a signal measurement system	September, 2003	Alexander et al.	345/781
20030227483	Displaying operations in an application using a graphical programming representation	December, 2003	Schultz et al.
20040142315	Device and method for changing the function of a virtual instrument	July, 2004	Bumann et al.	434/262
20040150650	Display capable of displaying images in response to signals of a plurality of signal formats	August, 2004	Mendelson et al.	345/589
20040221238	Automatic generation of programs with GUI controls for interactively setting or viewing values	November, 2004	Cifra et al.
20040246252	Method and apparatus for visualizing data	December, 2004	Morrow et al.	345/440